Skip to content

AI governance for worker-built apps

Governance for worker-built apps, the vibe-coded or citizen-developed apps staff build with AI, comes down to six things: an enabling acceptable use policy, risk tiers, an app registry with owners, data rules per tool, review scaled to risk, and records that show it all works. Most of it should live in the platform and the registry, not in documents. Most of it also reuses obligations and frameworks you already follow, such as privacy law, your audit scope and your vendor contracts.

Who this is for

IT managers, risk and compliance leads, and executives deciding how to govern apps staff build with AI. You get the six elements and where each one lives, the rule for adding a rule, and how this connects to the law and standards you already work with. About 6 minutes.

What are the six elements?

Each element has one canonical page. This page says what each one is for and links there; it doesn't repeat the rules.

Element What it does Where it lives
1. An enabling acceptable use policy Says who may build, with which tools and data, and the few rules with no exceptions Vibe coding policy template, with the policy on unsanctioned AI use (shadow AI policy) for amnesty and enforcement
2. Risk tiers Sets what each app needs, from a personal experiment to a critical process Risk tiers for worker-built apps
3. An app registry with owners Records every app, its owner and successor, its tier and its grants App registry and app ownership
4. Data rules per tool Says which data classes each approved tool may handle Can I use company data in an AI app? and the approved-tools list
5. Review scaled to risk Matches tests and review to the tier: a self-check for small apps, a business review and technical check from Important The verify gate in the gate matrix, run through checking an app before release
6. Records that show it works Produces the evidence an auditor, a customer or a regulator asks for Compliance for vibe-coded apps

The tiers hold the others together. Every worker-built app sits in one of four risk tiers (Sandbox, Team, Important or Critical), set by the highest answer to six questions about its data, users, internet reach, dependence, decisions about people and actions, and two floors apply at every tier. The policy points to the tiers, the registry records them, the data rules feed the first question, and the review and evidence scale with them.

Who decides what across these six is on roles and decision rights, part of the operating model for worker-built apps.

Where should governance live?

In the tools, wherever it can. A rule the platform enforces (sharing off by default, company sign-in, a blocked bypass mode, a cap on records changed per run) works on every app without anyone reading it. A rule in a PDF works only on the people who read it and remember it. Vendor guidance for low-code platforms does the same: it puts sharing and connector limits on the default environment rather than relying on a policy to keep builders inside them.2 Practitioners also recommend governed sandboxes over blocking for AI-built tools.1

The registry is the other home. When registration unlocks hosting, sign-in and data access, the registry stays current because people want what it gives them, and every review, owner check and retirement starts from it. That's a hypothesis to test in your pilot, not a proven result (A-001, on the registry page).

The documents still matter: the policy, the tier model and the Decision Records explain why the tools are set the way they are. Keep them short, and link instead of copying.

Don't: govern with policy alone

A policy with no guardrails in the platform and no registry to check against can't tell you whether anyone follows it. Saskatchewan's May 2026 low-code policy pairs its written rules with monitoring and named remedies (review, remediation, reassignment to IT, decommissioning).3 Pair each rule with the place it's enforced or checked.

Don't: ban and hope (AP12)

Governance that starts by forbidding AI tools, with nothing approved, hides use instead of stopping it. Start with an approved default and the discovery of what already exists. Sources are on failure patterns.

How do you decide whether to add a rule?

Evidence precedes rule. A new clause, gate or tier trigger is justified by an incident, a law or regulator's guidance, a published study, or an audit finding, never by a vendor pitch or a headline alone. Record each addition as a Decision Record with its evidence and a review date, using the decision record template.

The test cuts both ways. If a rule hasn't caught anything in a year and no law requires it, remove it at the next review. Every rule costs builders time, and heavy governance is how a program recreates the unsanctioned use it set out to replace.

Two more principles carry over from older governance practice:

  • Every control has an owner, named as a role. If nobody owns a control, it doesn't exist.
  • Map to public frameworks instead of inventing your own. Where a recognized standard covers a concern, cite it, so auditors get the crosswalk for free.

Which laws and standards does this touch?

Not legal advice

Not legal advice. This page summarizes laws as of October 2026 for a general audience. It was written with an AI legal-research persona and hasn't been reviewed by a lawyer for your situation. Ask your counsel.

No US or Canadian law regulates building apps with AI as such. Duties attach to what an app does, with one exception: Quebec requires a privacy impact assessment before building a system that handles personal information (Quebec Law 25). Each of the pages below holds the detail, so this section only says when to go there.

  • US and Canadian law. Privacy, sector, consumer-protection, breach and employment laws apply through an app's data, users and decisions. US and Canadian laws for AI-built apps maps each one to the control on this site that helps, and lists the items to stop and call counsel about.
  • Decisions about people. Apps that score, rank or help decide about someone's job, pay, credit, housing or access to services carry notice, explanation and review duties in several states and provinces. Start with apps that make decisions about people.
  • The EU AI Act. It matters to a North American business when an AI feature's output is used in the EU. Building internal apps with an AI tool creates almost no other duty. See the EU AI Act and worker-built apps.
  • Audits and attestations. SOC 2, ISO/IEC 27001 and SOX audits ask whether your controls cover the apps in their scope. Compliance for vibe-coded apps covers the evidence by tier.
  • Voluntary frameworks. The NIST AI Risk Management Framework4 and ISO/IEC 420015 give the governance shell: policy, roles, risk tolerance and impact assessment. Standards for AI-built apps holds the crosswalk.

Maps to: NIST AI RMF GOVERN 1.1 (legal and regulatory requirements understood) and GOVERN 1.6 (AI inventory); ISO/IEC 42001 clause 5.2 and control A.2.2 (AI policy); NIST CSF 2.0 ID.AM-02 (inventory of software and services) for the registry.

Don't: claim a framework makes you compliant

Following this site, or mapping controls to a framework, doesn't make anyone compliant with a law or certified against a standard. The NIST framework is voluntary and can't be "complied with". ISO/IEC 42001 certification needs an accredited audit, and mapping to it isn't certification. Say "we map our controls to", and keep the evidence (AP16).

Depends on your circumstances (C1, C2, C4)

If you process regulated data (C1), are a public body (C2), or customers and contracts ask about your AI use (C4), governance needs more evidence and earlier counsel involvement. Public bodies may have to publish their AI inventory and policy: US federal agencies must keep an AI use-case inventory and an acceptable-use policy under OMB M-25-21.6 All three circumstances are covered on compliance for vibe-coded apps.

Regulators and public-sector guidance favor enabled, inventoried, risk-tiered use over bans: OMB M-25-21 requires enablement-oriented use policies and inventories, and the UK government's AI Playbook asks for lifecycle management through to secure shutdown.7 For private businesses that's an analogy, not a rule (A-019).

What governance isn't

  • It isn't a committee. A standing committee that approves each app becomes a queue, and builders route around queues. Decision rights go to named roles, with the counsel route for the few cases that need a lawyer.
  • It isn't a PDF. See above: if a rule can be enforced in the platform, put it there.
  • It isn't a gate on everything. A Sandbox experiment needs no approval beyond the approved tool and the two floors. Review grows with the tier.
  • It isn't fixed. Review the policy every six months, and the tier questions whenever the registry's tier mix drifts.

Questions to ask your counsel

  1. Which of our existing policies (privacy, records, acceptable use, information security) already cover worker-built apps, and where are the gaps?
  2. Which worker-built apps fall inside our SOC 2, ISO 27001 or SOX audit scope?
  3. In which states, provinces and countries do the people our apps touch live or work, and which privacy and employment laws apply to us there?

Assumptions and evidence

  • A-019 (Medium; High for the public sector): we expect regulators to favor enabled, inventoried, risk-tiered use over bans, so this model matches what they expect; watch for any regulator that mandates prohibition by default for generative AI in general business use.

Evidence: government policies and guidance (US, UK, Australia, Saskatchewan) and practitioner assessment; no controlled study of governance models for worker-built apps. Australia's federal AI policy, for example, requires named accountable officials.8 Facts on this page are as of October 2026.

  1. Thoughtworks Technology Radar, "AI-accelerated shadow IT" (Caution; governance-first sandboxes), Apr 2026. https://www.thoughtworks.com/radar/techniques/ai-accelerated-shadow-it [vendor; a consultancy's practitioner assessment], accessed 2026-10-21. ↩

  2. Microsoft Learn, "Secure the default environment" (Power Platform adoption guidance: sharing limits and data policies on the default environment). https://learn.microsoft.com/en-us/power-platform/guidance/adoption/secure-default-environment [vendor], accessed 2026-10-21. ↩

  3. Government of Saskatchewan, Low-Code/No-Code Development and Maintenance Policy, issued May 2026. https://taskroom.saskatchewan.ca/-/media/project/taskroom/documents/policy/lowcodenocodedevelopmentandmaintenancepolicy.pdf [primary], accessed 2026-10-21. ↩

  4. NIST, AI Risk Management Framework (AI 100-1), 1.0, Jan 2023; under revision as of 2026. https://www.nist.gov/itl/ai-risk-management-framework [primary], accessed 2026-10-21. ↩

  5. ISO, ISO/IEC 42001:2023, AI management systems. https://www.iso.org/standard/81230.html [primary], accessed 2026-10-21. ↩

  6. US Office of Management and Budget, Memorandum M-25-21, "Accelerating Federal Use of AI through Innovation, Governance, and Public Trust", 3 Apr 2025. https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf [primary], accessed 2026-10-21. ↩

  7. UK Government, "Artificial Intelligence Playbook for the UK Government", 10 Feb 2025. https://www.gov.uk/government/publications/ai-playbook-for-the-uk-government/artificial-intelligence-playbook-for-the-uk-government-html [primary], accessed 2026-10-21. ↩

  8. Australian Digital Transformation Agency, "Responsible choices: new policy for using AI in the Australian Government" (accountable officials, transparency statements). https://www.dta.gov.au/blogs/responsible-choices-new-policy-using-ai-australian-government [primary], accessed 2026-10-21. ↩