Citizen Developers, Low-Code and the Non-Developer Who Builds

The development organisation has never been the only place where software is written. Case handlers build trackers, claims teams build dashboards, product owners build prototypes, and since generative AI arrived each of them can describe an application in a sentence and receive one. This chapter concerns D1 Frame, D3 Build and D5 Steward for the person who is not a developer and builds anyway: who that person is, which tools they use, what goes wrong when nobody knows the tool exists, how governance works when prohibition does not, where a prototype becomes production and who owns the result when its builder moves on. It matters to developers because the platform team, the tech lead and the architect are the people the rest of the organisation will call when a citizen-built tool fails.

The terms are used as follows. A citizen developer is an employee outside the development organisation who builds software for work, with a spreadsheet, a form or workflow builder, a low-code platform or a natural-language app builder. The research literature calls the wider group end-user programmers. A low-code platform provides visual building blocks, connectors to data and a hosting environment so that an application can be assembled with little or no hand-written code. A natural-language app builder generates the application, and often its database and hosting, from a description in ordinary language; the practice of building by conversation with an AI coding system is called vibe coding in Chapter 7. Shadow IT is software or a service that the organisation's IT function does not know about or has not approved. A maker is the platform vocabulary for a citizen developer inside a low-code product.

From prototype to production with promotion gates

Figure 19.1: From prototype to production: register entry, team use in a sandbox, four promotion gates passed before a pipeline promotes, and a separate route for tools that decide about people.

The argument has five steps. More people build, and AI lowers the barrier of syntax without lowering the barrier of knowing whether the result is right. The risks fall into data, access and continuity. Governance without prohibition rests on a register, templates and sandboxes, because bans do not appear to stop what they target. The line between prototype and production is drawn by use and by data and crossed through gates that the stewardship tests supply. Every tool has an owner who can leave, so support and sunset are decided at registration. A register entry with promotion criteria makes the steps reviewable.

The chapter builds on conclusions of the earlier volumes. AI Governance, Chapter 2, concluded that the usage mode, not the brand, sets the governance, and this book keeps that vocabulary from Mode 0 Ambient AI to Mode 5 Autonomous production agents (162, Nordqvist, 2026). AI Leader, Chapter 10, treated shadow AI as evidence that tasks had been allocated by people on their own initiative and set out the method of finding it by asking and by aggregate measurement, not by watching individuals (174, Nordqvist, 2026). AI Operations, Chapter 22, made a decision right a requirement with a holder and deputies, which is the form the owner and deputy of a tool take here (170, Nordqvist, 2026). Chapter 4 supplies the delegation ladder and the stewardship principle with its three tests, Name, Understand and Revert.

When anyone can build

Ko and colleagues opened their 2011 survey of end-user software engineering with the statement that most programs are written not by professional developers but by people with expertise in other domains, working towards goals for which they need computational support. They cite a projection from US Bureau of Labor Statistics data of fewer than 3 million professional programmers in the United States by 2012 against more than 55 million people using spreadsheets and databases at work, many of them writing formulas and queries (205, Ko et al., 2011). The second number counts users of a kind of tool, not programmers, and the projection is a US figure from before low-code platforms existed in their present form. It is used here for what it shows: building software outside the development organisation is old, large and mostly invisible to it. The survey also reports the finding that matters for this chapter, that end-user programmers face many of the same software engineering challenges as professionals, including understanding their requirements and making decisions about design, reuse, integration, testing and debugging (205, Ko et al., 2011). That is D1 Frame and D3 Build, done without the training, the review and the pipeline that the development organisation has around them.

The ladder of tools

The tools form a ladder, and the rungs differ in what the builder must understand. A spreadsheet with macros keeps logic and data in one file that the builder can see. A form or workflow builder hides the logic in configuration but keeps it inspectable. A low-code platform adds connectors, shared hosting and user management, and with them sharing, permissions and data flows that the builder may not have meant to create. A natural-language app builder or an agent adds generated code that the builder may be unable to read. At each rung the cost of producing the first working version falls and the cost of knowing why it works stays where it was.

What AI changes

AI changes the ladder, and the book separates what is observable from what is expected. It is observable that the major low-code vendors offer assistants that generate flows and applications from descriptions, and that natural-language builders host and publish what they generate. It is observable that such applications are deployed publicly by people who did not write them: Deng, Fan and Meng collected 9,041 open-source applications built with Claude Code and Lovable and audited 200 publicly deployed ones (209, Deng et al., 2026); the study is a preprint, and its sample is public applications, so it says nothing about the share of internal tools. It is expected, from the falling cost of the first version, that the number of builders in any organisation rises, and the registers of this chapter are where to watch it. The gain is real: a case handler who automates a manual reminder removes a delay that the development backlog would not have reached for a year.

Usage modes in citizen building

The usage modes of the series apply to the builder as they apply to the developer, and the table later in the chapter sets a ceiling for each. Two points matter here. Mode 0 Ambient AI is suggestion inside the spreadsheet or studio that the vendor switched on and nobody decided. Mode 4 Built AI applications, an application that calls a model itself, is within reach of a citizen builder in a few clicks, and then the tool is an AI system with a provider, a deployer and possibly a risk class, whoever assembled it (163, Nordqvist, 2026).

Shadow IT and its risks

Shadow IT is not a new category of fault. It is a mismatch of visibility: the organisation carries duties for software it cannot see. Three classes of risk follow, data, access and continuity, and a fourth, the legal role of the organisation, applies when the tool uses AI.

Quality: what older research measured

Panko reviewed the field audits of real organisational spreadsheets in 2000. Seven audits between 1987 and 2000 found errors in 24 per cent of 367 spreadsheets, and the audits from 1997 onwards, which used better methods, found errors in 91 per cent of 54; most audits reported only substantive errors, not all errors (206, Panko, 2000). The sample is old, the spreadsheets are not applications built with AI, and audit methods varied. The book's reading is a conclusion and not a measurement: software built by people who do not test it independently has a high base rate of errors, and AI does not remove the need for the independent check that the spreadsheet audits found missing. The test oracle must be independent of the generator, and for a citizen builder the generator and the author are the same person.

Data

Data risk starts with personal data. A controller that lets an unapproved builder or a consumer-tier assistant process personal data has no arrangement of the kind GDPR Article 28(1) asks for: the controller uses only processors that give sufficient guarantees, and processing is governed by a contract (4, European Union, 2016). Article 30(1) obliges the controller to maintain a record of processing activities, which a tool nobody registered is not in. Article 25 asks for data protection by design and by default, Article 32 for security appropriate to the risk, and Article 35(1) for an assessment of impact before processing that is likely to result in a high risk (4, European Union, 2016). These are the controller's duties, and the controller is the organisation, not the case handler who built the form.

The behaviour behind the risk has been surveyed. Gillespie and colleagues, funded by KPMG, surveyed more than 48,000 people in 47 countries between November 2024 and January 2025, 32,352 of them employees. Almost one in two employees who use AI reported doing so in ways that contravene organisational policies, 48 to 49 per cent reported uploading sensitive company information or copyrighted material to public AI tools, and 56 per cent reported using AI at work without knowing whether it was allowed (54, Gillespie et al., 2025). The data are self-reported, the authors note possible under-reporting, and the survey concerns AI use in general, not building. It supports the narrower point that use outpaces policy.

Access

Access failures are the best-documented class in low-code and AI-built applications, and the mechanism is the same in the cases below: a default or a missing rule exposes data to people who should not see it. In 2021 UpGuard reported 38 million records exposed through Power Apps portals of 47 entities, because lists had table permissions disabled by default; Microsoft first closed the report as by design, and later released a checking tool and made table permissions enabled by default for newly created portals (239, UpGuard, 2021). The report is a security vendor's, and Microsoft's account was not read for this book. The pattern recurs with natural-language builders. The National Vulnerability Database records CVE-2025-48757, an insufficient row-level security policy in Lovable through 15 April 2025 that lets unauthenticated remote attackers read or write arbitrary database tables of generated sites; the record is tagged disputed, with the supplier stating that each customer is responsible for protecting the application's data (240, NIST, 2025). The audit by Deng and colleagues found at least one vulnerability in 91.0 per cent of 200 publicly deployed vibe-coded applications, with 65.77 per cent of 1,186 vulnerabilities rated Critical or High, clustered in broken access control, injection and authentication failures (209, Deng et al., 2026). The conclusion drawn here is the book's own: when responsibility for a default is disputed between platform and customer, the organisation that holds the data has to assume that it is its own, and the control belongs at the platform boundary where it does not depend on the maker.

A related class is excessive agency. The OWASP project lists LLM06 Excessive Agency among the risks of applications built on large language models (230, OWASP, 2025), and a citizen-built agent given a broad connector so that it works at all has the exposure of a developer-built agent with broad credentials, without the mandate manifest that Chapter 8 requires. A catalogue record of July 2025 lists press reports that an agent on a hosted development platform ran destructive commands during a code freeze and that production data was lost; it lists no primary post-incident report, and the book uses it only as a reported illustration of why an agent's reach is set outside the agent (33, AI Incident Database, 2025).

Continuity

A tool is as durable as its owner's attention and its platform's lifecycle. The builder changes job and the tool runs on the builder's permissions or stops. A tool that calls a model depends on a model version that the provider will retire: one provider's documentation states that applications relying on its models may need occasional updates, that requests to retired models fail, and that publicly released models carry at least 60 days' notice (48, Anthropic, n.d.). A citizen-built Mode 4 tool that nobody maintains has a date on which it stops working, set by a third party. Ownership over time is the only control against it, which is why D5 Steward is in the opening of this chapter.

The legal role

When the tool uses AI, a further question arises that the maker is rarely in a position to answer. Under the AI Act a provider is a natural or legal person, public authority, agency or other body that develops an AI system and places it on the market or puts it into service under its own name or trademark, a deployer uses an AI system under its authority, and putting into service includes supply of the system for the provider's own use (Article 3(3), (4) and (11)) (1, European Union, 2024). An authority that builds a tool and uses it for its own purposes may therefore be both. Article 25(1)(c) treats a deployer that modifies the intended purpose of an AI system not classified as high-risk, so that it becomes high-risk, as the provider of that system (1, European Union, 2024). A case handler who asks a general-purpose assistant to rank benefit applications for the verification queue is near that line. The architectural implication, not legal advice, is that a tool which ranks or decides about a named person is not a citizen build at all. It belongs to the development organisation as a project with a mandate, an impact assessment and an AI Decision Record, and Chapter 24 returns to the instruments. AI Boss concluded that AI may direct work but may not, on its own, decide about people (167, Nordqvist, 2026), and the Level 4 prohibition on decisions about a named person's employment, pay, performance rating or access to work applies to what employees build as it does to what developers build.

Governance without prohibition

The simplest response to shadow IT is a ban, and it is the response with the weakest evidence. In the survey above, uploading sensitive company information or copyrighted material into public AI tools was most common among employees who reported that their organisation had banned generative AI or had a policy guiding its use, compared with those whose organisation had no policy or who were unsure; the reported shares were 67, 56, 33 and 38 per cent respectively; the authors read this as suggesting that bans may be ineffective and that policies alone do not guarantee compliance (54, Gillespie et al., 2025). The result is a correlation in self-reported data and does not show that a ban caused the behaviour. It is consistent with the position that AI Leader, Chapter 10, reached from the other direction: a sanctioned route must exist that is at least as good for the task as the unsanctioned one, since otherwise the prohibition fails (174, Nordqvist, 2026). The case for prohibition is not empty: some builds must be stopped, and the Level 4 prohibitions are such stops. The difference is that the prohibition is narrow and reasoned, and the default is a route.

Find it by asking and by service

Discovery follows the method of AI Leader: count which services the network and the platforms reach without identifying who, hold structured conversations with units about what they build and why, and offer a time-limited amnesty in which declaring a tool carries no consequence (174, Nordqvist, 2026). Covert monitoring of staff is never a method of this book. A measure that logs the tool use of identifiable people is a technical means suited to monitor behaviour or performance within BetrVG section 87(1) no. 6 and, under Swedish law, a matter for the employer's duty to negotiate before an important change under MBL section 11, and it is agreed with the representatives before use (9, Germany, n.d.); (12, Sveriges riksdag & Regeringskansliet, 1976). The register records the tool, the data and the owner role. It does not record how often a named person used it.

The register, the template and the sandbox

Three mechanisms carry the governance. The register is the list of tools that exist, with owner, data classes and a sunset date, kept in version control like the other records of the series. The template is the sanctioned route made easy: a starting point with approved connectors, logging and a data-protection notice already in place, so that following the rule is less work than avoiding it. The sandbox is an environment where a maker can build and share within a team without reaching production data or the whole organisation.

Platform documentation shows how this is done in one family of products, and the book describes it as a pattern, not as a recommendation of a product. Microsoft's guidance for Power Platform describes data policies that enforce which connectors are enabled in each environment and which can be used together, with connectors classified as business data only, no business data allowed or blocked; policies are scoped to an environment or a tenant, not to a user, and by default no data policies are implemented in the tenant (207, Microsoft, 2025). The same vendor's environment strategy describes the default environment as the place where personal productivity apps often start, routing of makers to personal developer environments, separate development, test and production environments, and pipelines that promote assets between them (208, Microsoft, 2026). The series uses these as examples of the control pattern of Architecture as Code (Chapter 10), policy written as configuration and enforced at the platform (161, Nordqvist, 2025). The limit of the claim is stated: the documentation describes features, and the book has no measurement of how effective they are in any organisation.

Four tiers

A register without tiers treats a personal macro and a benefits tracker alike. The tiers set the weight of governance by what can go wrong, in the manner of the tiered routing of AI Governance, Chapter 13, where decisions go to the lowest tier that can take them with evidence (162, Nordqvist, 2026). The definitions are the book's own and illustrative.

Tier	Test	Who answers	Governance
A, personal	Used only by the maker; no personal data of others; no write access to shared systems	The maker	Counted in the platform inventory, no individual entry; the platform expires it after 12 months without use
B, team	Used by colleagues in one unit; internal data only; no personal data of people outside the team	The unit head, with the maker named	Register entry; sandbox environment; review every 12 months
C, business	Personal data of citizens, customers or staff; money; a record of the organisation; more than one unit; or unattended running	A named owner and a deputy	Promotion gates, developer review, support path, review every 6 months
D, project	Ranks or decides about a named person; is or feeds a high-risk AI system; touches a security-critical path (authentication, authorisation, cryptography, payment, clinical or life-safety logic); or acts irreversibly on production data	The development organisation, as for any project	Not a citizen build; mandate, impact assessment, AI Decision Record and a named developer for review

Tier D is the Level 4 prohibitions of Chapter 4 applied to a different builder: a tool in a security-critical path has human review by a named developer, whoever wrote it. The tiers do not rank people. The same case handler may own a Tier A macro and a Tier C tracker.

Prototype and production

A prototype is a build whose purpose is to learn, and whose failure costs the maker's time. A production tool is one on which someone other than the maker depends. The line between them is crossed by use, not by code: a spreadsheet that colleagues begin to rely on is in production the week they begin, whatever its author called it. Three signals mark the crossing and each is observable without watching individuals: a second unit begins to use the tool, personal data of people outside the team enters it, or it begins to run unattended. Any of the three moves the tool to Tier C, and the register is where the move is recorded.

Promotion criteria

Promotion is a decision with criteria, and the criteria are the stewardship principle applied to the tool. Name: the owner and a deputy are named, and the deputy has passed a drill in which they find the switch-off and explain the data flow, in the decision-right form of AI Operations, Chapter 22 (170, Nordqvist, 2026). Understand: the owner or deputy can explain what the tool does and why, without the assistant that generated it, in one page showing the data flow and the permissions, and the tool passes test cases that someone other than the maker wrote. The independent oracle is the hard part, because the maker is both author and sole user; its owner is the process owner or the quality function, who hold the cases the tool must handle and the outcomes that are correct. Revert: the tool can be switched off, the manual process it replaced still works, and the data can be restored, each tested and recorded with date and result. Three further criteria are specific to this chapter. Data and access: data classes are recorded, the data protection officer has screened the tool and decided whether an impact assessment is needed, permissions follow least privilege and anonymous access is off. Support: a support path is named. Sunset: a review date and an end date are set at registration.

The promoting identity is not the maker. In the pattern of the platform documentation, pipelines move an asset from development to test to production (208, Microsoft, 2026), and the gate is the same one that Chapter 11 requires of a release: a gate that the change itself cannot alter. A maker who can edit the criteria, grant their own tool a production environment or approve their own test cases has a tool at Level 4 for a change to its own gates, which is a prohibition. The criteria for Tier C are therefore data in the repository of the platform team, changed by pull request, and a failing criterion fails the promotion.

Evidence, and its age

"Tested" is a claim and carries scope, date and result. A criterion in the register is recorded as met, not met or not tested, with the date and what was done, and it expires. The series convention is 90 days for usage evidence and 180 days for value evidence; this chapter applies 90 days to tests of a running tool, because the platform, the connectors and the model beneath it change. "Not tested" counts as not met. A register that shows 60 tools "reviewed" without saying what was reviewed, when and with what result is the equivalent of the acceptance-rate dashboard that Chapter 20 examines.

Promotion criteria as code

The criteria are kept as data. The values are illustrative.

promotion_criteria:
  version: "1.0"
  applies_to: tier-c
  name:
    owner_and_deputy_named: true
    deputy_drill_passed: true
  understand:
    one_page_data_flow_and_permissions: true
    independent_test_cases:
      minimum: 20
      written_by: not-the-maker
      evidence_age_max_days: 90
  revert:
    switch_off_tested: true
    manual_fallback_tested: true
    restore_test_age_max_days: 90
  data_and_access:
    data_classes_recorded: true
    dpo_screening: required
    dpia: required-if-screening-finds-high-risk   # GDPR Article 35(1)
    least_privilege_roles: true
    anonymous_access: forbidden
  support_and_sunset:
    support_path_named: true
    review_months: 6
    sunset_date: required
  promoted_by: platform-pipeline-identity         # never the maker
  criteria_changed_by: pull-request-to-platform-team

Support and sunset

The owner of a tool leaves more often than the tool does. The Name test therefore asks for two people, the owner and a deputy, with the unit head as the accountable role. The register is checked against a role event and not against a person's activity: when an owner changes job or leaves, the personnel process asks the unit head to name a new owner within a stated time, which is a question about a tool and does not involve watching the leaver. A tool without an owner after that time becomes read-only, then archived, then deleted, on periods the register's rules set. It is the rule that Chapter 12 states for repositories: ownership is a record.

Support divides by tier. Tier A is self-supported. Tier B is supported by the maker and the unit, with a community of makers where there is one. Tier C needs what any production service needs: a service record and a runbook of the kind AI Operations defined, an incident path into the service desk, and a change record for changes after promotion, so that the tool enters the operations loop with the rest of the estate (170, Nordqvist, 2026). The development organisation carries the cost, which is the price of lowering the barrier to building. The book's conclusion is that an organisation that counts the savings of citizen building and not the support it creates has an unmeasured liability, and the measure to keep is the number of Tier C tools per developer who can review them.

Sunset is a decision taken at registration, not at departure. Every Tier B and C entry has a sunset date, which the owner renews by showing use and passing the review. Records law adds a constraint in a public authority: source code, design documents and the data of a tool that supports a case may be requested under public-access rules and may need to be kept as records, so deletion is a decision for the archivist as well as the owner. Data protection law adds the opposite constraint, that personal data are kept no longer than the purpose requires. The sunset rule names both, and where they conflict the legal counsel decides. A tool that calls a model also sunsets when the model version is retired, so the register records the version and the published retirement date (48, Anthropic, n.d.).

A build-your-own-tool register

The register is the artefact of this chapter. It sits in version control with the other records of the book. It uses the code-ownership record family OWN-NR-* and OWN-HM-* of Chapter 12, extended with a range for registered tools, because ownership is what it records. Its entries state the tier, the owner, the deputy, the data classes and the state of each promotion criterion. The same file is the input to the sweep that finds tools without owners.

Practical guide: Creating a register entry and promotion criteria for a tool built by a case handler

Purpose. Register a tool that a non-developer has built, decide its tier, and either promote it through the gates or record exactly what is missing.

Roles. The case handler is the maker. The unit head is accountable. A deputy is named by the unit head. A developer from the integration and data team reviews the tool. The data protection officer screens the data. The process owner or the quality function supplies the independent test cases. The platform team runs the sandbox and the pipeline. The union representative for IT staff is informed of the design of the register, because it records owners.

Inputs. The tool itself, in its sandbox; a description of the task it supports and the manual process it replaced; the data it holds; the assistants used to build it, by usage mode; the promotion criteria of the tier.

Steps.

Describe the task. The maker writes what the tool is for, who uses it and what the manual fallback is. The unit head reads it and confirms.
Classify the tier. Apply the four tests. Any doubt moves the tool up one tier. If a Tier D test applies, stop and hand the tool to the development organisation as a project.
Name the owner and deputy. The unit head names both. The deputy performs the drill: finds the switch-off, explains the data flow and says which colleague would be affected if it stopped.
Record data and assistants. List the data classes, whether special categories or decisions about persons are involved, whether the tool contains AI, and which assistant produced what, by mode.
Obtain the independent cases. The process owner writes at least the minimum number of test cases and the correct outcomes. The maker does not see them in advance.
Review. The developer reads the tool or its generated configuration for access and data flow, runs the cases and records result and date. The developer reviews and does not become the owner.
Test the revert. Switch the tool off, run the manual fallback on sample cases, restore the data to a copy, and record each result.
Screen. The data protection officer screens the data and records whether an impact assessment is needed.
Promote or record. If every criterion is met, the platform pipeline promotes the tool; if not, the register records which are not met or not tested and the tool stays in the sandbox.
Set the dates. A review date by tier and a sunset date; the unit head signs.

Artefact. The register entry below, in version control, with the criteria file as its reference.

A register entry

The entry is illustrative and agrees with the profile of Nordvik Region. A case handler in the benefits unit has built a tracker in FormFlow, the low-code product of the Region's national SaaS framework, that records which supporting documents are missing from an application and lists the applications that are waiting. It holds the case reference and the document type, and no document content. It does not rank or decide.

id: OWN-NR-2030-0101
title: Missing-documents tracker, benefits unit
registered: 2030-10-21
updated: 2030-10-24
status: tier-c-conditional          # registered; not promoted
platform: FormFlow
environment: sandbox-benefits       # no production environment granted
maker_role: case handler, benefits unit
accountable: unit head, benefits unit
owner: case handler, benefits unit      # the maker; must pass Understand
deputy: second case handler, benefits unit
support:
  platform: IT service desk
  logic: integration and data team, business hours, on request
data:
  classes: [personal data of applicants: case reference, document type]
  special_category: false
  decides_about_persons: false
  ai_in_the_tool: none
  assistants_used_to_build: [mode-1 enterprise assistant, classification internal]
tier: C
tier_reason: personal data of applicants
criteria:
  name:
    state: met
    evidence: 2030-10-21 deputy drill passed
  understand:
    state: not-met
    evidence: independent cases written 0 of 20 minimum
  revert:
    state: not-tested
  data_and_access:
    state: met
    evidence: 2030-10-24 DPO screening, no impact assessment needed, anonymous access off
promotion_criteria: promotion_criteria.yaml@1.0
review_due: 2031-04-21
sunset: 2031-10-31

The state of the entry is the point. The tracker works, and a team relies on it, which is why it is in the register. It is not promoted, because one criterion is not met and one is not tested. The register says so and nobody has to ask.

Across the usage modes and the organisations

Across the usage modes

The table gives, for citizen building, the highest degree of delegation each usage mode has been allowed in a citizen-build profile. The profiles of Chapter 4, DLG-NR-DEV-01 and DLG-HM-DEV-01, cover developers. Neither covers the people who build in FormFlow or Flowdesk, which is the first finding of the sweeps described below. A second profile, called DLG-NR-DEV-02 here as an illustration, would set the ceilings below. The ceiling is not a licence, as in the profiles of the earlier chapters.

Mode	What the citizen builder does with it	Highest degree allowed	Condition
0 Ambient AI	Accepts completion and suggestions inside the spreadsheet or the studio	Level 1 Assisted	Recorded in the register after discovery; until decided, Level 0 on paper
1 Conversational assistants	Drafts formulas, flows and prototypes in the approved assistant	Level 1 Assisted	Tier A and B; no special-category data, credentials or decision rules
2 Embedded workplace assistants	Generates a flow or screen in the platform from a description	Level 2 Supervised	The maker approves each step and runs it against known cases; Tier C needs developer review
3 Agentic work tools	Lets an agent edit many components and run actions	None for citizen builders	Reserved to developers and the platform team under a mandate manifest
4 Built AI applications	Builds an application that calls a model itself	Level 1 Assisted for outputs to the maker	Tier C at least; named reviewer of outputs; never for decisions about persons
5 Autonomous production agents	An agent acting with its own identity in production	Not a citizen build	Developer-owned mandate only; the Region has none

The Level 4 prohibitions apply to citizen builds without change. No citizen build changes production without a gate the change cannot alter, touches a security-critical path without review by a named developer, changes its own mandate or gates, acts irreversibly on production data, or decides about a named person's employment, pay, performance rating or access to work.

Nordvik Region and Hansa Mutual

Nordvik Region finds spreadsheets and form builders in case handling. About 140 staff in the sectors build small applications and forms in FormFlow, about 60 applications of which 11 handle personal data (existing profile). The first sweep in October 2030, illustrative, started from the platform's own list of applications and from conversations with unit heads. The platform list is a lower bound: spreadsheets, local macros and unapproved builders are not on it. Of the 60, 31 were classed Tier A, 18 Tier B and 11 Tier C. One of the eleven was a rule list that a unit had built to order its own verification queue by urgency. That is a ranking of applicants for a benefit, the activity for which the Region treats its own benefits-triage system as high-risk under Annex III point 5(a) of the AI Act, and so it was reclassified as Tier D and taken out of FormFlow into the route for AI systems, with the legal counsel and the system owner of the triage system consulted, and the unit returned to its manual queue meanwhile. The tracker above is a second of the eleven. The Region has no Mode 5 agent and no citizen-build use of Mode 3, so the table's lower rows describe what is excluded. The union representative for IT staff was informed of the register's design under the negotiation pattern of MBL-NR-IT-2027-01, which negotiates tools that log engineers' queries; the register records tools and owner roles, and tool usage by named people is not collected.

Hansa Mutual finds app-builder prototypes in claims. About 400 builders in business units run 150 applications on the group's low-code platform Flowdesk, 23 of them touching personal data (existing profile). The first sweep, illustrative, classed 96 as Tier A, 31 as Tier B and 23 as Tier C. It also found a prototype outside Flowdesk: a claims team lead had used a natural-language app builder that the group had not contracted to produce a dashboard of open claims from an export of SVC-HM-001, and the service-level count of outbound traffic to the builder's domain showed it. The response was a conversation, not discipline. The Flowdesk sandbox and a template with a pseudonymised view of the claims data were offered as the sanctioned route, and the unsanctioned copy was closed once the dashboard had been rebuilt there. Of the 23 Tier C tools after the first quarter, 9 had met the promotion criteria, 11 were in remediation and 3 were retired. Under the group's change policy, which rests on the DORA requirements on ICT risk management, a Flowdesk tool that supports an important function needs a change record for a change after promotion, and the Hansa Forge package proxy and gateway are to apply to any tool that calls a model. Telemetry from low-code use is reported by team, never per named person, with a minimum group size of five, extending the rule that the draft annex KBV-IT-2024-DEV-01 sets for coding tools (Chapter 22). The Cyber Resilience Act questions are those of Chapter 24.

The two organisations differ in scale and constraint, and the difference decides the support model. Nordvik has few developers to review Tier C tools, so its limit is reviewer capacity. Hansa has more reviewers and a platform team of 24, so its limit is the number of external services a business unit can reach without the group knowing. Both found that the delegation profile written for developers did not cover the people who build most often.

Observable, expected, speculation

The three labels of AI Governance, Chapter 22, apply to every statement about the future of this chapter.

Observable. Non-developers build software in large numbers (Ko et al., a projection from 2005 reported in 2011); AI-built applications are publicly deployed (Deng et al., 2026); access failures from defaults recur across low-code and natural-language builders (UpGuard, 2021; NVD, 2025); platform vendors ship environments, data policies and promotion pipelines. The registers of the two organisations are illustrative.
Expected. Registers, tiers and promotion pipelines become ordinary practice in organisations of this size, because instruments in force assign duties to the controller, the deployer and the provider whoever typed the tool, and a duty of record is hard to meet without a register (GDPR Articles 25, 30 and 32; AI Act Articles 3 and 25). The support burden on development organisations rises with the number of Tier C tools.
Speculation. That most business software will be built by non-developers is plausible given the falling cost of the first version, and no study measures the share. A register kept for several years in organisations that report their sweeps would show it wrong if Tier C tools stay a small fraction of builds, and right if they do not. The author's own projection is kept to Chapter 29.

Summary

This chapter concerned D1 Frame, D3 Build and D5 Steward for the non-developer who builds. More people build, with tools from spreadsheets to natural-language app builders, and AI lowers the barrier of producing the first version without lowering the barrier of knowing whether it is right. The risks are data, access and continuity, with a legal-role question when the tool uses AI; audits of spreadsheets found errors in most of the better-audited sample, and incidents and an audit of publicly deployed AI-built applications show missing or default access rules as the recurring failure.

Governance without prohibition rests on a register, templates and sandboxes, with discovery by asking and by service and never by watching named individuals. The evidence, self-reported and correlational, suggests that bans do not stop the behaviour they target, so the sanctioned route has to be at least as good as the unsanctioned one. Four tiers set the weight of governance by what can go wrong, and Tier D, a tool that ranks or decides about a named person or sits in a security-critical path, is not a citizen build. Promotion is the stewardship principle applied to the tool: Name an owner and a deputy, Understand with a one-page data flow and test cases the maker did not write, Revert with a tested switch-off and fallback, plus data, access, support and sunset, and a pipeline identity promotes, never the maker.

The register entry and the criteria file are the artefacts, and the entry for a case handler's tracker shows an honest state: one criterion met, one not met, one not tested, and no promotion. The delegation ladder applies with its ceiling, no citizen build above Level 2 Supervised in the table, and the Level 4 prohibitions unchanged. Chapter 20 turns to the measurement of AI adoption, where the same rule holds, that a claim carries what was measured, how, when and with what result, and Chapter 22 returns to the works-council terms for what the register may and may not collect.

Sources

European Parliament and Council of the European Union. Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union, 12 July 2024. (1, European Union, 2024)
European Parliament and Council of the European Union. Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, 4 May 2016. (4, European Union, 2016)
Federal Republic of Germany. Betriebsverfassungsgesetz (BetrVG), section 87. Federal Ministry of Justice. (9, Germany, n.d.)
Sveriges riksdag, Regeringskansliet. Lag (1976:580) om medbestämmande i arbetslivet (MBL), 10 to 12 §§. Svensk författningssamling. (12, Sveriges riksdag & Regeringskansliet, 1976)
AI Incident Database. Incident 1152: LLM-Driven Replit Agent Reportedly Executed Unauthorized Destructive Commands During Code Freeze, Leading to Loss of Production Data. 2025. (33, AI Incident Database, 2025)
Anthropic. Model deprecations. Claude Platform documentation. (48, Anthropic, n.d.)
Gillespie, N., Lockey, S., Ward, T., Macdade, A. & Hassed, G. Trust, Attitudes and Use of Artificial Intelligence: A Global Study 2025. The University of Melbourne and KPMG, 2025. (54, Gillespie et al., 2025)
OWASP Gen AI Security Project. OWASP Top 10 for LLM Applications 2025. OWASP Foundation, 2025. (230, OWASP, 2025)
Nordqvist, G. Architecture as Code. The Architecture as Code Series, Book 1. (161, Nordqvist, 2025)
Nordqvist, G. AI Governance. The Architecture as Code Series, Book 2. (162, Nordqvist, 2026)
Nordqvist, G. AI Platform and Security. The Architecture as Code Series, Book 3. (163, Nordqvist, 2026)
Nordqvist, G. AI Boss. The Architecture as Code Series, Book 7. (167, Nordqvist, 2026)
Nordqvist, G. AI Operations. The Architecture as Code Series, Book 10. (170, Nordqvist, 2026)
Nordqvist, G. AI Leader. The Architecture as Code Series, Book 11. (174, Nordqvist, 2026)
Ko, A. J., Abraham, R., Beckwith, L., et al. The State of the Art in End-User Software Engineering. ACM Computing Surveys 43(3), Article 21, 2011. (205, Ko et al., 2011)
Panko, R. R. Spreadsheet Errors: What We Know. What We Think We Can Do. Proceedings of the EuSpRIG Spreadsheet Risk Symposium, 2000. (206, Panko, 2000)
UpGuard. By Design: How Default Permissions on Microsoft Power Apps Exposed Millions. UpGuard Research, 2021. (239, UpGuard, 2021)
Microsoft. Implement a data policy strategy. Microsoft Learn, Power Platform guidance, 2025. (207, Microsoft, 2025)
Microsoft. Develop a tenant environment strategy to adopt Power Platform at scale. Microsoft Learn, Power Platform guidance, 2026. (208, Microsoft, 2026)
National Institute of Standards and Technology. CVE-2025-48757 Detail. National Vulnerability Database, 2025. (240, NIST, 2025)
Deng, J., Fan, Z. & Meng, R. Understanding the (In)Security of Vibe-Coded Applications. arXiv:2606.23130, 2026. (209, Deng et al., 2026)