A vendor risk assessment template for AI app builders

Someone on your team wants to build an internal tool with an AI app builder, and they’ve asked you to sign off. You don’t want to block a genuinely useful thing, but you also can’t approve a tool you’ve never assessed against how your company handles data. What you need is a short, repeatable way to score the tool before it goes near real customer or employee data.

This post gives you that: a plain vendor risk assessment you can copy into a doc and fill in for any AI builder, plus what each answer actually tells you.

Why AI builders need their own assessment

A normal SaaS vendor assessment assumes a company on the other side with a security team, a status page, and a signed contract. AI app builders bend that model in two ways.

First, the tool your colleague ships is partly their creation. The builder gives them a database, auth, and hosting, but the app logic, the data model, and the access rules were generated on the fly. So you’re assessing two things at once: the platform vendor, and the specific app built on it.

Second, these tools are adopted bottom-up. A marketer or an ops lead signs up with a personal login and a company credit card, and the first time compliance hears about it is when it already holds live data. That’s the pattern behind most “shadow IT” risk. Your assessment needs to be short enough that people actually run it before they build, not a 200-question form they route around.

The goal isn’t to say no. It’s to sort tools into three buckets: fine as-is, fine with fixes, and not fit for real personal data.

The template

Copy this into a shared doc. One row per question, three columns: the question, the answer, and a risk rating (Low / Medium / High). Fill it in for the specific app, not just the platform.

Section 1: Data

1. What personal data will this app hold? (names, emails, health data, payment data, none)
2. Whose data is it? (customers, employees, suppliers, the public)
3. Does it hold any special-category data? (health, biometrics, religion, and similar. If yes, treat the whole assessment as High risk.)
4. Roughly how many people’s data will be in it?

Section 2: Location and contract

5. Which country do the servers and database sit in?
6. If that’s outside the UK/EU, what legal transfer mechanism is in place?
7. Is there a signed data processing agreement (DPA) with the platform vendor?
8. Does the vendor use sub-processors, and are they listed?

Section 3: Access and security

9. Who can log into the app, and how is access granted and removed?
10. Is login protected by multi-factor authentication?
11. Are there any API keys or secrets, and where are they stored? (a key sitting in the app’s front-end code is High risk on its own)
12. Is data encrypted in transit and at rest?

Section 4: Continuity

13. Are there backups, and has a restore ever actually been tested?
14. If the person who built the app leaves, who can maintain it?
15. Can you export all the data out of the tool if you need to leave?

Section 5: Ownership

16. Who is the named owner of this app inside your company?
17. When will this assessment be reviewed again? (set a date, 12 months is a sensible default)

How to score it

You don’t need a fancy formula. Use this rule of thumb:

• Any High in Section 1 or 2 (special-category data, no DPA, data outside the UK/EU with no transfer mechanism) means the tool should not hold real data until that’s fixed.
• Two or more Highs anywhere else means fix before launch.
• All Low, or a couple of Mediums with a plan means proceed, with the review date set.

The most common failures we see are questions 7, 11, and 13: no DPA, a secret key exposed in front-end code, and backups that exist but have never been restored. None of those are visible from the app’s screen. You only find them by asking.

A quick note on question 7. If the app holds personal data, a DPA with the platform is not optional under GDPR (Article 28). “The tool works fine” says nothing about whether that paperwork exists. Check for an actual signed or click-accepted agreement, not a marketing page that mentions security.

A worked example

Say a colleague built a customer feedback tracker with an AI builder. You run the template. Section 1: it holds names, emails, and free-text comments from customers, no special-category data, roughly 2,000 people. Section 2: the servers are in a US region with no transfer mechanism named, and no DPA is in place. Section 3: everyone on the team shares one login, and there’s an API key visible in the app’s front-end code. Section 4: no backups have ever been tested. Section 5: no named owner.

Scoring that: US data with no transfer mechanism and no DPA are two Highs in Sections 1 and 2, so the tool should not hold real data until those are fixed. The shared login and the exposed key are two more Highs in Section 3. This isn’t a tool to ban; it’s a tool with a clear, short fix list: move the data to the EU or add a transfer mechanism, sign a DPA, give each person their own login, move the key out of front-end code, test a backup, and name an owner. Every one of those is a task, not a mystery, because the template surfaced it.

The value of running the template isn’t the score itself. It’s that it converts a vague “is this thing okay?” into a concrete list someone can work through in an afternoon.

Or, we do it for you

Running this assessment across a handful of AI-built tools, and then fixing the Highs, is exactly the work we take on. We host these apps properly, sign the DPA, lock down secrets, and test the backups, so the scary rows turn green. Start with a free audit on one tool on our for-SME page.

FAQ

How often should we re-run this?

Once a year for a stable tool, and again any time the app changes what data it holds or who can access it. Set the review date in question 17 so it doesn’t get forgotten. A tool that was Low risk last year can drift to High the moment someone adds a new field or a new integration.

The tool is only used by three people internally. Do we still need this?

Yes, if it touches personal data. GDPR doesn’t have a “too small to matter” exemption. A three-person internal tool holding employee data still needs a DPA, a known data location, and a way to answer an access request. The assessment just takes ten minutes at that size.

What if a question gets a “we don’t know”?

Treat “don’t know” as High until proven otherwise. Not knowing where your data lives or whether a key is exposed is itself the risk. The point of the template is to turn unknowns into either a confirmed answer or a task with an owner.

Can we use this for non-AI SaaS too?

Mostly, yes. The data, location, contract, and access sections apply to any vendor. The AI-builder-specific traps are questions 11 and 14: exposed secrets in generated code, and single-person ownership of an app nobody else understands.