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.
Download it as DOCX, adapt it and take it to your leadership. It's for IT, the security manager, or whoever in the company was handed the topic, and it works with any tool. You don't need Fabrika for it.
Updated 28 September 2026
Opens in Word, Google Docs or LibreOffice. The places to fill in are in square brackets.
Each with a short reason, so the people who build know why the rule is there.
An app register with a filled-in example, and questions for each app's author.
Why isn't an AI use policy enough?
The policy templates you find today mostly deal with what people put into an AI chat: which data mustn't go in and who checks the output. That's needed. But when a colleague builds an app with AI and the whole team starts using it, you have something else: software that 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
Researchers at RedAccess found about 380,000 publicly reachable apps built with tools like Lovable, Replit, Base44 or Netlify. Around 5,000 held sensitive company or personal data, often with no sign-in at all.
Security Boulevard, 2026 ↗“You cannot govern what you cannot find.”
How do you find out what's already running?
Rules only make sense once you know what to apply them to. An inventory takes a few days, and you'll find most apps in three places: with people, in accounts and on the network.
Say up front that you're not looking for someone to blame. Whoever tells you about their app is helping. Whoever fears punishment hides it.
Where to look
Ask people
A short form, or five minutes at each team meeting: have you built anything with AI that more than one person uses? The questions for authors are below and in the template's appendix.
Go through payments and expenses
Subscriptions to Lovable, Replit, Cursor, Vercel, Netlify, Supabase or AI plans on company cards and in expense reports. An app that runs usually has someone paying for it.
Check sign-ins with company accounts
In the Google Workspace or Microsoft Entra admin console you can see the third-party apps people have granted access through their company account. Unfamiliar names are worth a question.
Search for links on typical domains
Addresses ending in lovable.app, vercel.app, netlify.app, replit.app or pages.dev in shared documents, Teams, Slack and bookmarks. That's where apps live when nobody has moved them.
Look at your own domain
Check the subdomains in your DNS and the certificates issued for your domain, which are public, for example through crt.sh. An unknown subdomain often means an app you don't know about.
What to ask about each app
- 1. What is it for and how many people use it? Anyone outside the company?
- 2. What data is in it? Personal, customer, financial?
- 3. Where does it run, at what address, and can anyone reach it without signing in?
- 4. How do people sign in, and who adds and removes access?
- 5. What was it built with, and whose account do those services run on? Who pays?
- 6. Where is the code, and can anyone besides the author change it?
- 7. Where is the data stored, and is it backed up?
- 8. What does it connect to, and with which keys or passwords?
- 9. What happens if it stops working tomorrow?
| Column | What goes in it |
|---|---|
| App and purpose | Name, and one sentence on what it's for |
| Level | 1 personal, 2 team, 3 sensitive (see the rules below) |
| Owner | Who answers for it on the company's behalf, not necessarily the author |
| Author and tool | Who built it and in what: Lovable, Cursor, Excel with macros… |
| Users | How many, and whether people outside the company use it |
| Data | Personal, customer, financial, or nothing sensitive |
| Where it runs | Address, service, and whose account |
| Sign-in | Company account, password, or none |
| Code and keys | Where the code is and where keys and passwords are stored |
| Connections | Which systems it touches: accounting, ERP, e-shop, email |
| Decision | Keep, fix, move elsewhere or switch off, and by when |
The same table, with a filled-in example, is in the template's appendix.
What should the rules cover?
Twelve points, each written out in the template. Every one comes with a reason, because people work around a rule they don't understand.
- 01
Who may build, and with what
Anyone may build, but in tools the company has approved, and through company accounts and AI plans, not personal ones.
WhyWhat gets built on a personal account is invisible to the company. When the person leaves, the account leaves with them.
- 02
A register and an owner
Every app more than one person uses is in a register and has an owner who answers for it on the company's behalf.
WhyNobody looks after an app nobody knows about. The owner is who you ask when something happens.
- 03
Three levels of risk
Personal tool, team app, sensitive app. The higher the level, the more rules apply.
WhyOne person's calculator doesn't need the same approval as a customer portal. When 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 apps approved for it. Test data for building and trying things out.
WhyGDPR applies to an app with personal data just as it does to software you buy, including reporting a breach to the authority within 72 hours.
- 05
Where it may run and who may publish it
Only in places the company has approved, and never without sign-in. Only a named person may put an app on the internet or let outside people in.
WhyThe most common problem isn't a bug in the code. It's an app that anyone with the link can open.
- 06
Sign-in with a company account
People sign in to team apps with their company account, access is granted by role, and the owner reviews it regularly. No shared passwords.
WhyWhen someone leaves, you block one account and their access ends everywhere.
- 07
Keys and passwords outside the code
API keys and database passwords don't go in code, in shared documents or in prompts for AI.
WhyCode gets copied, shared and pasted into AI tools. A key inside it will be seen by more people than it should.
- 08
Who approves changes
The code lives in a company repository, changes are tried outside production, and for sensitive apps a second person reviews them before deployment.
WhyIn Veracode's tests, AI-written code had a security flaw in 45 % of tasks. A second pair of eyes is the cheapest insurance.
Veracode, 2025 ↗ - 09
Backups and recovery
The owner and IT decide what gets backed up, how often, and how quickly the data has to be back. A restore gets tried every so often.
WhyA backup nobody has tried to restore is just a hope.
- 10
When the author leaves
Someone else knows every team app, each has a short description, and the accounts belong to the company.
WhyAn app built with AI often depends on one person. When they leave, nobody knows where it runs or how it changes.
- 11
How to report an incident
Anyone who finds a leak or something suspicious reports it straight away to one place and doesn't try to fix it alone first.
WhyFor personal data you have 72 hours to report. NIS2 national laws set short deadlines too, 24 hours for a significant incident in the Czech Republic. The clock starts when the problem is found.
- 12
When to switch an app off
When it has no owner, nobody uses it, it doesn't meet the rules even by the agreed date, or an incident calls for it. Decide what happens to the data first.
WhyAn app nobody uses still holds data and still has an open door.
Three levels in the template
The more people use an app and the more sensitive the data, the more rules apply. Adjust the boundaries to fit your company.
1 Personal tool
Only the author uses it, it holds no personal or confidential data and can't be reached from the internet.
Approved tools, the data rules and keys outside the code. It doesn't go in the register.
2 Team app
Several people in the company use it, or it works with company data, including basic employee data.
All twelve rules. Entry in the register and approval before other people start using it.
3 Sensitive app
Customer, partner or financial data, special categories of personal data, connections to key systems, or users outside the company.
As level 2, plus a second person reviews every change, agreed backups and a data protection review.
Download the template and make it yours
The DOCX opens in Word, Google Docs and LibreOffice. The places to fill in are highlighted in [square brackets]: who owns the rules, which tools are approved, where incidents get reported. Strike out what doesn't apply to you.
Before you publish it, go through it with the people who build the apps. A rule nobody can follow gets worked around.
DOCX · about 45 KB · updated 28 September 2026
This is a template to adapt, not legal advice. If your company falls under NIS2 or processes sensitive personal data, have a lawyer or your security manager review the final text.
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?
Rules on paper depend on people following them. On Fabrika, part of them is enforced by the platform, so nobody can skip them, not even by accident. The rest stays with you and with how you set the rules.
AI
The AI runs on your own plan, and nothing is trained on your data.
Records
Sign-ins are logged, and changes to access and roles are kept. You see them in the console.
Where apps run
Apps run in your company's own installation of the platform, in a cloud account registered to your company with Cloudflare or Zerops, or AWS if you prefer. They have no public address of their own; every request goes through one entry point that lets in only verified users.
Sign-in and roles
People sign in with their company account through Google, Microsoft Entra or Okta. Multi-factor authentication works the way your company has it set up. Roles are set per app, and you decide who gets which.
Keys and passwords
The cloud provider holds the values. Each app sees only its own, and through the platform they can be written but never read back.
Changes
Every change goes through Git and we review it before it's deployed. Testing and production are separate environments, and every deployment has its own record.
Backups
We set up backups and recovery with you, to the extent you need. That's our service, not something the platform does on its own.
When the author leaves
The code is in Git, the rules are in the platform, and we've seen every change during review. The next person picks up where the last one stopped.
Incidents
The platform collects errors from all apps in one place. We help find out what happened, fix it and put together the documents for any report you have to file.
What stays with you
Who may build, what data belongs in which app, who gets which role, when an app gets switched off, and any reports to the authorities. And the register of apps that run outside Fabrika.
When are the rules enough without Fabrika?
Often. The template is written to work with anything, and for many companies it's all they need.
The apps are personal tools
If people mostly build tools for themselves, with no personal data and nothing reachable from the internet, level 1 and a bit of awareness will do.
Your IT can run and review apps
If you have your own hosting, company sign-in and someone who goes through changes, the rules just help you write it down. You don't need another platform.
People build in a tool you already manage
If they build in something you already have under control, Power Apps for example, the rules fill in what the tool doesn't cover on its own.
You'd rather slow the building down
Then the inventory and the switch-off rule will serve you. Just expect that a ban won't stop people, it only sends them elsewhere.
“Bans work no better than prohibition did.”
When Fabrika makes sense
When team apps keep multiplying, they work with customer or financial data, and you don't have the capacity to secure and watch each one separately. Then it pays to have the rules enforced by a platform and every change reviewed by someone.
What people ask about the rules
Is this a policy we can publish as it is?
It's a template. Fill in the places in square brackets, strike out what doesn't apply, and publish it the way you publish other internal policies. It isn't legal advice.
Does it replace our AI use policy?
No, it adds to it. An AI use policy covers what people type into a chat. These rules cover the apps that come out of it. If you have no AI use policy yet, the template's data rule covers the bare minimum.
Do we need rules like this because of NIS2?
If your company falls under NIS2, check what your national rules ask for around developing and maintaining systems. The Czech implementation, for example, requires security requirements for that even in the lower regime (Decree 410/2025 Coll., Section 3). The 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?
If more than one person uses it or it works with company data, yes. The rules don't care what an app was built in, only what it does and what data it holds.
Won't it put people off building?
Not if the rules are tiered. Personal tools barely have to meet anything; the bar rises with the number of users and the sensitivity of the data. And when people know how to get an app into production properly, they don't need to hide it.
Who should own the rules?
Whoever is responsible for IT or cyber security in your company. Leadership should approve them, so they apply the same way across every team.
How often should we update them?
The tools change fast. Plan a review once a year and whenever something bigger changes, for example when the company approves a new tool.
Can we change the template however we like?
Yes. Adapt it to your company and use it internally as you need.
Go through it with us in half an hour.
Tell us what your people have built and where the rules pinch. We'll tell you which parts could be enforced technically on Fabrika and which will stay on paper. Bring your leadership or your lawyer along if you like.