A policy template for the apps your people build with AI
An AI use policy covers what people type into a chat. This template covers the apps they build with AI: who may build, with what data, where an app may run and what happens when its author leaves.
For IT, the security manager or whoever was handed the topic. It works with any tool; you don't need Fabrika for it.
Updated 22 October 2026
Word, Google Docs or LibreOffice.
Each with a reason.
With a filled-in example.
Why isn't an AI use policy enough?
When a colleague builds an app with AI and the whole team starts using it, it's software: it runs somewhere, holds data and needs someone to look after it.
An AI use policy covers
- which AI tools are allowed
- what data may go into a chat
- who checks and answers for what the AI writes
Rules for apps also cover
- where the app runs and whether it's reachable from the internet
- who signs in and who grants access
- where the code, the keys and the data are
- who approves changes before they go live
- what happens when the author leaves
- when an app gets switched off
apps with sensitive data, open to anyone
RedAccess found about 380,000 public apps built with tools like Lovable, Replit, Base44 or Netlify. Around 5,000 held sensitive company or personal data, often with no sign-in.
Security Boulevard, 2026 ↗“You cannot govern what you cannot find.”
How do you find out what's already running?
An inventory takes a few days. Say up front you're not looking for someone to blame: whoever fears punishment hides their app.
Where to look
- 01
Ask people
A short form or five minutes at each team meeting: have you built anything with AI that more than one person uses?
- 02
Go through payments and expenses
Lovable, Replit, Cursor, Vercel, Netlify, Supabase or AI plans on company cards and expense reports.
- 03
Check sign-ins with company accounts
The Google Workspace or Microsoft Entra console shows third-party apps people granted access through their company account.
- 04
Search for links on typical domains
lovable.app, vercel.app, netlify.app, replit.app or pages.dev in shared documents, Teams, Slack and bookmarks.
- 05
Look at your own domain
Subdomains in your DNS and public certificates for your domain, for example via crt.sh. An unknown subdomain often means an unknown app.
What to write down about each app
- App and purpose
- Level 1–3 (see the rules below)
- Owner, not necessarily the author
- Author and tool
- Users, including outside the company
- Data: personal, customer, financial
- Where it runs, on whose account, and whether it opens without sign-in
- Sign-in: company account, password, none
- Where the code, keys and passwords are
- Connections: accounting, ERP, e-shop, email
- Decision: keep, fix, move or switch off, and by when
The template's appendix has the same table with a filled-in example, and the questions to ask each author.
What should the rules cover?
Twelve points. The template gives a reason for each, because people work around a rule they don't understand.
- 01
Who may build, and with what
Anyone, in tools the company has approved, through company accounts and AI plans.
WhyA personal account is invisible to the company and leaves with the person.
- 02
A register and an owner
Every app more than one person uses is registered and has an owner who answers for it.
- 03
Three levels of risk
Personal tool, team app, sensitive app. The higher the level, the more rules apply.
WhyWhen everything is equally strict, people stop reporting even the small things.
- 04
What data an app may use
Personal, customer and financial data only in approved apps. Test data for building.
WhyGDPR applies as to any software, including reporting a breach within 72 hours.
- 05
Where it may run and who may publish it
Only in approved places, never without sign-in. Only a named person may open an app to the internet or outsiders.
WhyThe most common problem is an app anyone with the link can open.
- 06
Sign-in with a company account
Company accounts, access by role, reviewed regularly by the owner. No shared passwords.
- 07
Keys and passwords outside the code
API keys and database passwords stay out of code, shared documents and AI prompts.
WhyCode gets copied and pasted into AI tools, and the key with it.
- 08
Who approves changes
Code in a company repository, changes tried outside production, a second reviewer for sensitive apps.
WhyIn Veracode's tests, AI-written code had a security flaw in 45 % of tasks.
Veracode, 2025 ↗ - 09
Backups and recovery
The owner and IT decide what is backed up, how often and how fast it must be back. Restores get tried.
- 10
When the author leaves
Someone else knows every team app, each has a short description, and the accounts belong to the company.
WhyOtherwise nobody knows where the app runs or how it changes.
- 11
How to report an incident
Report a leak or anything suspicious straight away to one place, don't fix it alone first.
Why72 hours for personal data; NIS2 laws are short too, 24 hours for a significant incident in the Czech Republic. The clock starts at detection.
- 12
When to switch an app off
No owner, no users, rules still unmet by the agreed date, or an incident. Decide about the data first.
Three levels in the template
Adjust the boundaries to fit your company.
1 Personal tool
Only the author uses it, no personal or confidential data, not reachable from the internet.
Approved tools, the data rules, keys outside the code. Not registered.
2 Team app
Several people use it, or it works with company data, including basic employee data.
All twelve rules. Registered and approved before others start using it.
3 Sensitive app
Customer, partner or financial data, special categories of personal data, key systems, or outside users.
As level 2, plus a second reviewer for every change, agreed backups and a data protection review.
Download the template and make it yours
Fill in the [square brackets]: who owns the rules, which tools are approved, where incidents get reported. Strike out what doesn't apply. Before you publish it, go through it with the people who build the apps.
DOCX · about 45 KB · updated 28 September 2026
A template, not legal advice. If you fall under NIS2 or process sensitive personal data, have a lawyer or your security manager review the final text. You may adapt it freely for internal use.
What's inside
- Purpose and scope
- Roles: author, app owner, policy owner
- Three levels of risk
- Twelve rules, each with a reason
- Exceptions and regular review
- Appendix A: questions for the app's author
- Appendix B: app register with a filled-in example
How does it work with Fabrika?
On Fabrika the platform enforces part of the rules, so nobody can skip them, not even by accident.
AI
Runs on your own plan. Nothing is trained on your data.
Records
Sign-ins and changes to access and roles, visible in the console.
Where apps run
In your own installation, in a cloud account in your company's name, usually on Zerops, or on AWS on request. No public addresses; one entry point lets in only verified users.
Sign-in and roles
Company account through your identity provider (Entra ID, Google Workspace, Okta) with your multi-factor setup. You assign roles per app.
Keys and passwords
Held by the cloud provider. Each app sees only its own; they can be written but never read back.
Changes
Through Git, with separate test and production and a record of every deployment. A deploy that widens access waits for a person's approval, and we also review every change.
Backups
Set up with you as our service; the platform doesn't do it on its own.
When the author leaves
The code is in Git and we've seen every change, so the next person picks it up.
Incidents
Errors from all apps in one place. We help find the cause, fix it and prepare documents for any report.
What stays with you
Who may build, what data goes where, who gets which role, when an app is switched off, reports to the authorities, and the register of apps outside Fabrika.
When are the rules enough without Fabrika?
Often. The template works with anything.
The apps are personal tools
No personal data, nothing reachable from the internet: level 1 and a bit of awareness will do.
Your IT can run and review apps
With your own hosting, company sign-in and someone who reviews changes, you just need it written down.
People build in a tool you already manage
In Power Apps, for example, the rules fill in what the tool doesn't cover.
You'd rather slow the building down
The inventory and the switch-off rule will serve you. A ban won't stop people, it only sends them elsewhere.
“Bans work no better than prohibition did.”
When Fabrika makes sense
Team apps keep multiplying, they work with customer or financial data, and you can't secure and watch each one separately.
What people ask about the rules
Does it replace our AI use policy?
No, it adds to it. If you don't have one yet, the template's data rule covers the bare minimum.
Do we need rules like this because of NIS2?
Check what your national rules ask about developing and maintaining systems. The Czech implementation requires security requirements for that even in the lower regime (Decree 410/2025 Coll., Section 3), and apps your people build are that kind of development. Whether it applies to you is best checked with a lawyer.
Does this cover Excel with macros or Power Apps too?
Yes, if more than one person uses it or it works with company data. What matters is what an app does and what data it holds, not what it was built in.
Won't it put people off building?
Not if the rules are tiered: personal tools barely have to meet anything. And when people know how to get an app into production properly, they don't need to hide it.
Who should own the rules, and how often should we update them?
Whoever is responsible for IT or cyber security, approved by leadership so they apply the same in every team. Review them once a year and whenever something bigger changes, such as a newly approved tool.
Go through it with us in half an hour.
Tell us what your people have built and where the rules pinch. We'll say what Fabrika could enforce technically and what stays on paper.