CEO's AI Tool Approval Checklist: 10 Questions Before You Say Yes

CEO's AI Tool Approval Checklist: 10 Questions Before You Say Yes

Your CTO wants to roll out Cursor. A dev is already using ChatGPT for everything. Someone installed Notion AI last week without asking.

At a glance: Ten questions a CEO should answer before approving any AI tool for the team: data handling, vendor DPA, training opt-out, employee scope, and incident response readiness. Takes 30 minutes; prevents most of the costly mistakes.

You have a decision to make, and not much framework for making it.

This checklist is 10 questions. It takes 30 minutes. It covers the things that cause real problems: source code leaving your environment, data used to train competitor models, no way to audit what happened after an incident.

Run it once per tool before you approve. Keep the answers in a doc.

TL;DR: Ten questions a CEO should answer before approving any AI tool for the team: data handling, vendor DPA, training opt-out, employee scope, and incident response readiness. Takes 30 minutes; prevents most of the costly mistakes.

Before you start

If you do not have a list of which tools your team is currently using, start there. Shadow AI, tools people use without approval, is more common than most CEOs think. See Governing Embedded AI in Third-Party Tools before running this checklist.

Question 1: Is this tool using our data to train their model?

This is the question most people ask first, and rightly so. If a tool trains on your code or prompts, your internal logic, architecture decisions, and proprietary patterns are potentially showing up in outputs for other users.

How to check:

• Look for "Data Controls," "Privacy Settings," or "Training" in account settings.
• Look for a Data Processing Agreement (DPA), enterprise plans usually have one.

What each major tool does by default:

Action: Verify, screenshot the setting, and save it in your approved tools doc.

Question 2: Does source code leave our environment?

This is different from question 1. Even if a tool does not train on your data, code may still transit their servers. That matters because: if their infrastructure is breached, your code is exposed. If you have NDA obligations with clients, transmitting their code to a third party may violate the agreement.

Reality check by tool:

• Cursor / GitHub Copilot: Yes, code context is sent to servers on every completion request. This is how the product works. There is no offline mode.
• ChatGPT: Only if your dev pastes code into the chat manually.
• Claude via API: Yes, but Anthropic does not retain prompts after the request completes (per current policy).
• Copilot with local models (Ollama, etc.): Code stays local.

Action: Decide your risk tolerance. For most startups without regulated client data, Cursor Business is an acceptable risk. For teams handling client source code under NDA, get explicit written confirmation from the vendor or run a local model.

Question 3: How long is our data retained? Can it be deleted?

Even if a tool does not train on your data, it may store prompts and outputs for days or weeks. That data is a liability: it can be subpoenaed, breached, or handed to authorities.

Retention by tool (approximate, verify with current policy):

• Cursor: Up to 30 days, deletion request available.
• ChatGPT: Until you delete the conversation or account.
• Claude API: No retention after request completes.
• Notion AI: Processed but not stored separately per policy.

Action: Find the "Data Retention" section in each tool's Privacy Policy. If you cannot find a clear answer in 5 minutes, that is a red flag. Escalate to vendor support before approving.

Question 4: If there is a breach, how fast do they notify us?

Most CEOs skip this question. It is the most important one after a breach happens.

GDPR requires notification within 72 hours. But that obligation is on vendors only if they process EU personal data and you are in scope. For a Vietnamese startup with no EU customers, you likely have no legal guarantee of notification timing.

What to look for:

• "Security Incident Notification" in Terms of Service.
• "Breach Notification" in the DPA.

Action: Search the Terms of Service for "incident" or "breach." If there is no clause, document that you have no contractual notification right and decide if that is acceptable.

Question 5: Are your devs using personal accounts for work?

This is the most common problem, and it is easy to miss.

A dev using their personal ChatGPT free account for work tasks means:

• Training is ON by default (you cannot turn it off on their behalf).
• No audit log, you cannot see what was shared.
• If they leave the company, you cannot revoke access or retrieve history.

Action:

1. Ask directly: "Is anyone using a personal AI account for work?"
2. Mandate company accounts for all work-related AI use.
3. Add this to your onboarding checklist.

Question 6: Do we have audit logs?

If something goes wrong, a dev shares a client's credentials in a prompt, or sensitive code ends up somewhere unexpected, can you reconstruct what happened?

Audit log availability:

Action: If you are on a personal or free plan, you are operating without a safety net. For any tool used with company data, upgrade to a plan with audit logs. The cost is usually $20-40/user/month. The cost of not having logs during an incident is much higher.

Question 7: Can we fully off-board if we stop using the tool?

Before you commit to a tool, test the exit.

Create a test account. Use it briefly. Then request account deletion and data erasure. See what happens. Some vendors confirm deletion within days. Others take weeks, require a support ticket, or have unclear policies.

Action: Do this test before company-wide rollout. If you cannot get a clear confirmation of data deletion, assume the data stays indefinitely.

Question 8: Does the tool have SOC 2 or ISO 27001 certification?

These certifications mean an independent auditor has reviewed the vendor's security practices. They are not perfect, but they are a meaningful baseline signal.

Status of common tools:

Action: Check the vendor's Trust or Security page. No certification does not mean the tool is insecure, many good tools are pre-certification. But it means you are trusting their self-assessment, not an external audit.

Question 9: Who owns the output the AI generates?

Your devs are generating code, documents, and analysis using AI. In most cases, the vendor's terms say you own the output. But there are nuances worth knowing.

Current policies:

• Cursor, ChatGPT, Claude: You own the output per current Terms of Service.
• Exception: Do not use AI to generate content that could infringe on third-party IP (e.g., training data with copyrighted code).

Unresolved question: If two companies independently generate nearly identical code using the same AI tool, who owns it? There is no clear case law yet.

Action: Read the IP ownership clause in Terms of Service before using AI for anything you plan to patent or treat as a core trade secret.

Question 10: Does your team know what you just learned?

The best policy in the world does not help if only the CEO has read it.

Most security incidents involving AI tools come down to a dev not knowing the rules, not malice, just ignorance. They did not know their personal ChatGPT had training ON. They did not know pasting a client's API keys into a prompt was a problem.

Action:

1. Run a 30-minute team briefing. Walk through this checklist together.
2. Create a one-page "Approved AI Tools" doc: which tools are approved, which are prohibited, what account type to use.
3. Add it to your onboarding checklist for new hires.

Template: AI Acceptable Use Policy for Small Teams

Auto-reject: 6 red flags that should block approval immediately

Run this before the 10-question checklist. If any apply, stop and do not approve until resolved.

A tool that hits any of these is not necessarily bad software. It may be fine for personal use. It is not approved for company work until the issue is resolved.

A tiered approval process: low, medium, high risk

Not every tool needs the full 10-question review. A tiered approach saves time and focuses scrutiny where it matters.

Low risk (expedited review, 1-2 days): Tools that don't touch company data, such as productivity assistants used only with public information, writing aids where no proprietary content is entered. Verify training policy and run questions 1, 8, 10. Document the outcome.

Medium risk (standard review, this checklist, 1 week): Tools that process internal data, source code, or customer information. Run all 10 questions. Require company-managed accounts.

High risk (extended review, 2-4 weeks): Tools used for employment decisions, credit assessments, access to essential services, or any use case covered by EU AI Act Annex III. Add a legal review, fundamental rights impact assessment, and explicit board-level sign-off. These are the tools that create personal liability exposure for the CEO.

Set a review cadence: low-risk tools, annually. Medium-risk, every 6 months or when the vendor changes their data policy. High-risk, every 90 days until compliance posture is stable.

CEO personal liability: what you're actually signing off on

When you approve an AI tool, you are making a governance decision that attaches to you personally in several regulatory contexts:

EU AI Act (December 2, 2027): Deployers of high-risk AI systems have documented obligations. If your company is a deployer and a serious incident occurs, the question regulators ask is not just "did the company comply" but "did the responsible person exercise due diligence?" A documented approval process is your evidence. An undocumented one is not.

GDPR: If an AI tool processes EU personal data and lacks a valid DPA, your company is potentially the data controller without a processor agreement. The DPA is not optional paperwork; it is a legal requirement. Approving a tool without one creates a compliance gap the CEO signed off on.

US state laws: Several US states now have AI-specific requirements for employment and consumer decisions. Colorado SB 189 (effective February 1, 2026), FCRA adverse action requirements for AI-assisted hiring, and NYC Local Law 144 all impose obligations on deployers. "I didn't know the tool was in scope" is not a defense once you've formally approved its use.

The documentation from this checklist is not busywork. It is your record that you asked the right questions before deployment.

After the checklist: what to document

Run this checklist before approving any new AI tool and save the answers. If a vendor changes their data handling policy or you onboard a contractor with codebase access, re-run the relevant questions, you do not need to start from zero. Treat the document below as a living record updated each time your AI tool stack changes.

Keep a simple doc with these columns:

Review this doc every 6 months, or when a vendor announces a policy change.

August 2026 update: EU AI Act deployer obligations

If your team operates in the EU or serves EU customers, the December 2, 2027 EU AI Act deadline adds three checks to this approval process.

Before approving any AI tool for employment decisions, credit scoring, or access to essential services: Classify it against Annex III. These are the EU AI Act's high-risk AI system categories. If the tool falls into one of these categories, you have deployer obligations beyond standard vendor due diligence: a fundamental rights impact assessment, documented human oversight procedures, and records of use. The quickest check: ask the vendor "Do you have an EU Declaration of Conformity or CE marking for use in this context?" A compliant vendor should be able to answer.

Vendor contract check: Standard SaaS agreements were not written around EU AI Act deployer obligations. Before renewing or signing AI vendor contracts in 2026, run the AI vendor contract red flags checklist alongside this one. The 12 red flags it covers, including training data opt-out defaults, model change notice periods, incident notification timelines, are now compliance gaps, not just negotiating points.

Incident response: If an AI tool causes or contributes to a serious incident affecting EU residents, EU AI Act Article 73 requires the provider to notify the relevant national competent authority within 15 days. Your approval doc should confirm: does this vendor have a contractual obligation to notify you of serious incidents, and within what timeline? If no such obligation exists in the contract, you may not know about a serious incident until well after the 15-day clock has run. See the AI incident response plan guide for the full framework.

Related resources

• AI Acceptable Use Policy Template, what to tell your team in writing
• Shadow AI: What It Is and How to Prevent It, find tools that are already in use
• AI Vendor Evaluation Checklist, deeper due diligence for paid contracts
• AI Tool Register Template, track all approved tools in one place
• Free AI Register Template, 12-field spreadsheet for EU AI Act Article 70 compliance
• GDPR-Compliant AI Assistants Comparison, side-by-side scoring of 6 major AI assistants before you approve one
• VC AI Governance Due Diligence Checklist, 18 questions investors will ask about your AI governance
• AI Regulatory Readiness Scorecard, 25-question self-assessment before signing off on new AI tools
• AI Risk Decisioning Governance, extra checklist for tools that make automated decisions
• California SB 942 AI Transparency Compliance, required if approving generative AI for California customers
• TAKE IT DOWN Act Enforcement, platform obligations for AI-generated content removal

Related Reading

• AI project intake checklist: 6-phase workflow for approving new AI tools
• AI governance guide for small teams
• AI tool register template
• AI vendor due diligence checklist
• AI acceptable use policy template
• AI regulation deadline calendar 2026, every jurisdiction
• EU AI Act GPAI compliance checklist, August 2 deadline
• ChatGPT vs Claude vs Gemini enterprise compliance 2026: the complete com