Skip to content

Approve an AI tool or app builder

To approve an AI tool or app builder, check it against a short minimum standard: a business-tier contract with no training on your data and defined retention, company sign-in and admin controls, audit logs, agent permission controls, apps that stay private by default, and data export. Approve it per data class (Public, Internal, Confidential, Restricted), not yes or no. Answer requests in days, and plan the exit when you approve the entry. As of October 2026.

Who this is for

IT managers, procurement and security leads who decide which AI tools and app builders workers may use. About 9 minutes.

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.

What is the minimum standard?

A tool goes on the list only for the data classes whose evidence you hold: a document or a tested setting, not a questionnaire answer. In the Public and Internal lane, IT approves on its own read of business-tier terms, company sign-in, the tested settings below and the tool's documented data handling. The Confidential and Restricted lane adds the full contract-terms read, a current security report, and counsel's read of the data processing agreement and any regulated-data addenda.

Area Minimum How you check it
Contract Business-tier terms, a data processing agreement, no training on your data, defined retention and deletion Read the contract terms, not the marketing page
Identity Company sign-in (SAML or OIDC), automatic deprovisioning (SCIM or equivalent), role-based admin; the admin can restrict third-party OAuth consent and scope or disable personal API tokens Test that removing a user revokes tokens, not just the login
Data handling Documented handling of prompts, outputs and files; a choice of data location where you need it Ask for the retention and region options
Logs Audit logs per user, exportable Export a sample
App builder defaults (if it builds apps) Private by default; the admin can disable anonymous or "anyone with the link" sharing; deny-by-default data rules Publish a test app; confirm it isn't reachable without sign-in
Agent controls (if it has agents) Limits on what an agent may read, write and call; a tool-use log; the admin can disable permission-bypass modes; scoped tokens Try to forbid production writes and to turn on a bypass mode; read the default permissions
Assurance (Confidential and Restricted lane) A current independent security report scoped to the product you'd use See contract terms
Exit Documented data export and termination terms Run a test export

Don't: approve a builder that can't keep an app private

A builder tool that can't keep a Sandbox app private isn't approved for Sandbox use. This is Floor 2 of the risk tiers: no internet reach without company sign-in below Important (AP1). Public-by-default apps and open data rules are the documented exposure pattern; see exposed data and secrets.1

Check the licence tier. SSO, audit logs and agent controls are sometimes sold only in a premium licence. Confirm the tier you buy carries them, or the rows above stay unmet in practice.

Depends on your circumstances (C5)

If nobody owns identity or access today, fix that first. Most rows above assume you can enforce company sign-in and remove leavers' access.

Fast-moving

As of October 2026. Check the review date. Vendors change terms, tiers and features often. Treat each approval as dated.

How do requests work, and how fast?

A worker or team names the tool, the data class and the use. Log the request (the intake form or the tools mailbox). If an app is waiting on it, that app's tier comes from the six tier questions. If the tool is already approved for that class, the answer is yes the same day; otherwise run the plan below. The IT/platform owner approves new tools (decision rights) for named classes, with conditions, or declines with the reason and an approved alternative. The five-day target is a hypothesis (A-030): log the real days. The plan assumes no in-house counsel or procurement team.

Day Do Output
1 Triage: name the data classes asked for, check the list, choose the lane Lane chosen
2–3 Trial: set up company sign-in, test the minimum-standard settings, export a sample log, run a test export. Security checks identity, logs and agent controls Tested-settings notes
4 Read the vendor's terms against the contract-terms table; counsel or procurement, where you have them, reads them too Gaps list
5 Decide, score if there are candidates (scorecard), and record Decision Record and list entry

Depends on your circumstances (C1)

If you process regulated data and have no in-house counsel, send outside counsel the Confidential and Restricted rows, the vendor's DPA and your gaps list on day 4, with a turnaround agreed in advance. Approve Public and Internal without waiting; don't approve the higher classes until counsel has read. With no procurement team, the IT/platform owner signs.

Don't: take weeks, ban with no alternative, or approve on a questionnaire

A ban without a sanctioned alternative doesn't stop use; it hides it (AP12).1 We expect builders to use the approved path if answers come within days (A-002, A-030); test it by counting requests that arrive after a decline. Approve a default tool first, then narrow the exceptions (shadow AI policy). Self-scored vendor answers aren't evidence.

How do you record which data classes each tool is approved for?

Approve a tool per data class: Public, Internal, Confidential and Restricted, as defined in Q1 of the risk tiers. A no-training business contract may suffice for Internal data and not for Restricted data, which can need a business associate agreement, a payment-card responsibility matrix or counsel's review first. The list is the evidence for the AI-feature approval gate: an app that sends data to a service not approved for that class is blocked. With a SOC 2 report, it's also vendor-risk evidence for CC9.2 (good practice).2

Give each built-in AI feature its own row, because the gate asks about the feature. It counts when it processes the app's data at runtime (AI used only to write the app doesn't), needs no separate approval when listed for that class, and is blocked when it isn't.

Each row records: the tool, licence tier and owner role; the capability (app builder, workflow tool, spreadsheet, coding agent, model API, hosting); each data class marked yes, no or with conditions; the built-in AI features, each with its own classes; conditions ("company sign-in only", "region set to X"); the DPA version and renewal date; the assurance report type, period and review date, with its subservice organizations and the customer controls it expects (CUECs); allowed extensions and MCP servers; and the approval and next-review dates.

Illustrative composite

An invented list for a business with three tools.

Tool Capability Public Internal Confidential Restricted Built-in AI features
Tool A Spreadsheet Yes Yes Yes, company sign-in only No AI formula: Public and Internal only
Tool B Workflow automation Yes Yes No No AI step: Public only
Tool C AI app builder Yes Yes Counsel review first No App generation: not used for runtime data

Which extensions, plugins and MCP servers are allowed?

Treat every extension, plugin and MCP server as its own vendor decision, because it runs with the access you give it. Allow-list them, pin versions, and review what each can read and write. Don't let workers add them freely to an approved tool: an extension an agent can call is a path into your data and systems (AP7).1 Approve MCP servers and connectors against the MCP security baseline, and use the MCP security baseline (CSV) as the checklist.

What contract terms should you require from an AI vendor?

Ask for these terms before any personal or Confidential data goes in, and have counsel read the actual contract. The list is good practice, not a legal checklist; no term makes you compliant on its own. Download it as a spreadsheet: contract-terms-checklist.csv, which also carries the legal reasons and the "maps to" controls. Prompt to Prototype, Approve an AI tool or app builder, https://prompt-to-prototype.com/platform/approve-tools/, as of October 2026. Licensed CC BY-SA 4.0.

The "Maps to" column points to controls you may already run: ISO/IEC 27001:2022 Annex A.5.19–5.26 (supplier relationships, cloud services and incident management),3 SOC 2 CC9.2 and C1.1,2 PCI DSS 4.0.1 Requirement 12.84 and NIST CSF 2.0 GV.SC.5

Term What to check Why it matters (examples) Maps to
Training use Off in the contract, not only a setting; covers prompts, outputs, files and telemetry; survives a change of tier; the carve-outs (feedback, "de-identified" data, abuse monitoring); notice before terms change Trade-secret "reasonable measures";6 CCPA service providers may improve their services within limits, and whether training fits is unsettled,78 so write no-training in ISO A.5.20; SOC 2 C1.1
Human review Whether vendor staff can read content, and how to opt out Confidentiality and privilege (ask counsel) ISO A.5.20
Retention and deletion Retention for prompts, outputs and logs; zero-retention option; deletion on termination; behavior under a legal hold Litigation can override a retention promise; your AI logs can be discoverable9 ISO A.5.20, A.5.23
Sub-processors A published list; notice of changes; a right to object; the same terms passed down Processor terms: CCPA and other state laws,710 Quebec s. 18.3,15 PIPEDA,13 GDPR Art. 2816 ISO A.5.19, A.5.21; SOC 2 CC9.2
Data location Where data is processed and stored; ownership links to a country of concern; the EU or UK transfer mechanism Quebec s. 17 assessment and agreement;15 US: the DOJ bulk sensitive-data rule (28 CFR Part 202) if a vendor or sub-processor is linked to a country of concern11 ISO A.5.23
Breach notice A fixed number of hours; who is told; what is shared; help with your own notices State, Canadian and sector notice duties1714 (breach and incident duties) ISO A.5.24–5.26
Security commitments A current SOC 2 Type II report or ISO/IEC 27001 certificate scoped to the product; encryption; SSO and multi-factor; tenant isolation Vendor-risk criteria;2 GLBA service-provider oversight18 ISO A.5.22; PCI 12.8
Audit and assurance rights Reports, questionnaires, pen-test summaries; regulator access if you're in finance GLBA periodic assessment18 ISO A.5.22; CSF GV.SC
Regulated-data addenda A HIPAA business associate agreement;19 a payment-card responsibility matrix;4 a DPA for EU or Quebec data Needed before that class goes on the list PCI 12.8.5
Indemnity Output IP claims covered? Conditions, exclusions, caps, control of the defense A backstop; often on business tiers only, rarely for personal accounts (observed, not verified per vendor; IP and licensing) —
AI-specific Notice of model changes; deployer documentation; accuracy claims you'd repeat Colorado SB 26-18912 and EU AI Act Art. 26 deployer duties (EU AI Act); the FTC Act20 CSF GV.SC
Exit Export format, transition period, deletion certificate Continuity; Quebec portability15 ISO A.5.23

EU and UK transfers matter only if the GDPR applies (Art. 3).16 A vendor can then rely on the EU-US Data Privacy Framework21 if its DPF List entry covers your data type (HR or non-HR);23 for UK data, the UK Extension, the IDTA or the UK Addendum.24 Keep standard contractual clauses as a fallback while the DPF challenge is on appeal (DPF status).22

Don't: assume the vendor secured it (AP3)

The vendor's security report lists customer controls you're still expected to perform, such as reviewing user access and protecting API keys.1 Record them. Tell your compliance owner if an app in audit scope changes platform: the compliance owner's change-management and evidence requirements apply at whatever tier the app is, and an audit-scope app gets no minimum tier (the audit-scope flag).

How do you onboard, offboard and exit a tool?

Onboard: set up company sign-in, admin roles, logging and spend alerts before the first user; add the list entry; record the tool in the app registry for any app that uses it; start with a limited group. Offboard: announce the date, export data and logs under the exit clause, move or retire the apps that use it, revoke tokens, confirm deletion, update the list, and keep what the contract and any hold require.

Write the exit plan with the approval: what would make you leave (a price or terms change, an incident, an acquisition), who decides, how data comes out, and which approved alternative takes over; keep a second tool approved for important uses. No exit plan, no approval for Confidential or Restricted classes. Re-review each tool yearly, and on any contract change, acquisition or vendor incident.

If several AI tools are already in use (C9), don't start by banning: inventory them, score and consolidate, give each remaining exception an owner, a reason and an expiry, and announce the alternative before you block anything.

How do you score and compare AI tools?

Use it to choose between candidates, and at renewal if the price or terms change. Download it: tool-scorecard.csv, which says what "meets the minimum" means per dimension. Prompt to Prototype, Approve an AI tool or app builder, https://prompt-to-prototype.com/platform/approve-tools/, as of October 2026. Licensed CC BY-SA 4.0. It replaces the older vendor selection worksheet, which will redirect here.

Score each dimension 0 to 3 from evidence (0 fails the minimum; 1 meets it with caveats; 2 meets all stated needs; 3 exceeds them), multiply by the weight and sum; the maximum is 300. Only Veto dimensions can rule a tool out: a 0 there disqualifies it whatever its total.

Dimension Weight Veto?
Data handling 15 Veto
IP and indemnity 15 Weighted
Identity and admin controls (including Floor 2 for app builders) 10 Veto
Security assurance 10 Veto (Confidential and Restricted classes)
Regulatory fit 10 Veto (for the classes requested)
Agent controls 10 Veto (where the tool has agents)
Operational reliability 10 Weighted
Integration 8 Weighted
Exit terms 7 Weighted
Price predictability 5 Weighted

Don't: let a total override a failed veto, or rank by vendor

Re-weight only before scoring, and record it in the Decision Record. Reviewers score alone on documents and trials, not demos, then discuss gaps of more than a point. Name a primary and a tested fallback. This page ranks no vendors.

How do you record an approval decision?

Use the Decision Record template, titled by capability and data classes ("Approve an AI app builder for Internal data"). Record the lane, the candidates and "do nothing", the classes and conditions approved, the signers (IT/platform owner; security, counsel and procurement where you have them), accepted risks, and the review triggers: the date, a contract change, an incident or a regulatory change.

Questions to ask your counsel

  1. What do our AI vendor contracts say on each term above, including indemnity caps and conditions, and do they differ by licence tier?
  2. Do they include the processor terms our privacy laws require (CCPA and other states, PIPEDA, GDPR), and does Quebec require an assessment and agreement before data leaves the province?
  3. Is any vendor or sub-processor linked to a country of concern under the DOJ bulk-data rule, and do we exceed its thresholds?
  4. Which tools need a business associate agreement or a card responsibility matrix before that class goes on the list?
  5. Are prompts, outputs and agent logs in our retention schedule, and can each tool suspend deletion on a legal hold?
  6. Could a public AI tool undermine trade-secret status or privilege, and which builders or hosts are subservice organizations in our SOC 2 or ISO 27001 scope?
  7. For EU or UK data, is the vendor's DPF or UK Extension listing current, and should we also use standard contractual clauses?

Assumptions and evidence

  • A-002. We expect builders use a low-power default path if exceptions are answered within days; test this by tracking request-to-answer time and declines followed by unapproved use. Confidence: Low (hypothesis).
  • A-025. The platform itself can fail, so an approved tool is not a safe tool. Confidence: Medium.
  • A-030. We expect intake answers can be given within five working days; test this on the same log. Confidence: Low (hypothesis).
  • A-040. We expect a business has, or can quickly adopt, a four-class data scheme so that per-class approval works. Test this by asking whether the list can be filled in for your top three tools. Confidence: Low (hypothesis).

Evidence: statutes, regulations and standards for the contract terms; no controlled study of approval turnaround or of how scorecards affect outcomes. The term list is good practice, not a legal checklist. The DPF appeal status is secondary-sourced.

Facts on this page are as of October 2026.

  1. Failure patterns AP1, AP3, AP7 and AP12 are described with their sources on failure patterns. [primary] Accessed 2026-10-21. ↩↩↩↩

  2. AICPA, 2017 Trust Services Criteria (with 2022 points of focus), criteria CC9.2, "The entity assesses and manages risks associated with vendors and business partners", and C1.1. Free registration required. [standard] Accessed 2026-10-21. ↩↩↩

  3. ISO, ISO/IEC 27001:2022, Annex A controls 5.19–5.26. [standard] The standard is sold; the control titles are public. Accessed 2026-10-21. ↩

  4. PCI Security Standards Council, PCI DSS v4.0.1 document library, Requirement 12.8 (third-party service providers) and 12.8.5. [standard] Accessed 2026-10-21. ↩↩

  5. NIST, Cybersecurity Framework 2.0, function GV.SC (supply-chain risk management). [standard] Accessed 2026-10-21. ↩

  6. US Code, 18 U.S.C. §1836 et seq. (Defend Trade Secrets Act), with "reasonable measures" in §1839(3). [statute] Accessed 2026-10-21. ↩

  7. California Code of Regulations, tit. 11, §7051 (contract requirements for service providers and contractors). [primary] Accessed 2026-10-21. ↩↩

  8. California Code of Regulations, tit. 11, §7050(a)(3), allowing a service provider to use personal information to build or improve the quality of its services, but not to build or modify household or individual profiles or to serve another business. Whether training a general model fits is unsettled (this page's reading; ask counsel). [primary] Accessed 2026-10-21. ↩

  9. Cornell Law School, Federal Rule of Civil Procedure 26(b)(1) (scope of discovery) and Rule 37(e) (sanctions for failing to preserve electronically stored information). [primary] Accessed 2026-10-21. ↩

  10. IAPP, US State Privacy Legislation Tracker (updated 8 Sep 2026); most state comprehensive privacy laws, for example Virginia, Colorado and Connecticut, require a contract between a controller and its processors. [secondary tracker] Accessed 2026-10-21. ↩

  11. US Department of Justice, 28 CFR Part 202, effective 8 Apr 2025: vendor, employment and investment agreements that give a "country of concern" or covered person access to bulk US sensitive personal data are restricted unless security requirements are met. Bulk thresholds (§202.205) include personal health or financial data on more than 10,000 US persons, biometric identifiers on more than 1,000 and covered personal identifiers on more than 100,000; countries of concern (§202.601) are China, Cuba, Iran, North Korea, Russia and Venezuela. [statute] Accessed 2026-10-21. ↩

  12. Colorado General Assembly, SB 26-189, deployer duties from 1 Jan 2027. [statute] Accessed 2026-10-21. ↩

  13. Government of Canada, Personal Information Protection and Electronic Documents Act, accountability principle and breach reporting. [statute] Accessed 2026-10-21. ↩

  14. Government of Canada, Breach of Security Safeguards Regulations (SOR/2018-64): the "real risk of significant harm" report and the 24-month record-keeping duty. [statute] Accessed 2026-10-21. ↩

  15. Québec, Act respecting the protection of personal information in the private sector, CQLR c. P-39.1, ss. 3.3, 3.5–3.8 (incident duties and register), 17 (communication outside Quebec, including to a US-hosted AI service) and 18.3 (a written contract with a service provider). [statute] The site blocks automated fetches; the text was checked in the legal research file. Accessed 2026-10-21. ↩↩↩

  16. EU, Regulation (EU) 2016/679 (GDPR), Art. 3 (scope) and Art. 28 (processor). [statute] Accessed 2026-10-21. ↩↩

  17. National Conference of State Legislatures, Security breach notification laws. [primary] A summary of state statutes. Accessed 2026-10-21. ↩

  18. Cornell Law School, 16 CFR §314.4 (FTC Safeguards Rule), paragraph (f), oversight of service providers and periodic assessment. [statute] Accessed 2026-10-21. ↩↩

  19. Cornell Law School, 45 CFR §164.504(e), business associate contracts. [statute] Accessed 2026-10-21. ↩

  20. Cornell Law School, 15 U.S.C. §45 (FTC Act §5), unfair or deceptive acts or practices. [statute] Accessed 2026-10-21. ↩

  21. European Commission, Implementing Decision (EU) 2023/1795 on the EU-US Data Privacy Framework, 10 July 2023. [primary] Accessed 2026-10-21. ↩

  22. Court of Justice of the EU, case C-703/25 P, appeal against the General Court's 3 September 2025 judgment dismissing the Latombe challenge (T-553/23). [court] Appeal status is from secondary sources (law-firm commentary, December 2025, and a June 2026 report); the docket wasn't read. Accessed 2026-10-21. ↩

  23. US Department of Commerce, Data Privacy Framework List. [primary] Accessed 2026-10-21. ↩

  24. UK Government, UK-US data bridge supporting documents, on the UK Extension to the DPF. [regulator] Accessed 2026-10-21. ↩