How to get IT to approve your AI tool: a one-page checklist
Bring IT into the idea while it is still small
Start with the work you want to improve and the platform you already know. Agree together on which steps should be consistent, which settings belong to each person, which actions need review and who will maintain the tool.
For example, an invoice helper can use a common exception checklist and approval packet while each operator retains their own access. The builder owns the business logic; IT reviews connections and consequential actions.
The security team toolkit shows what a reviewer will check.
You don’t need to be technical to get a tool approved. You need to answer the questions IT will ask before they ask them. Copy this list, fill it in, and send it with your request.
What it does
- In one or two sentences, what does the tool do?
- Who would use it, and roughly how many people?
- How much time does it save, or what does it help with?
What it touches
- Which apps does it read from? (For example: email, calendar, CRM, support desk.)
- Which apps does it write to or send from, if any?
- Does it handle customer, candidate or employee information?
Does it have all three risk legs?
- Does it read text written outside your company, such as emails, tickets, CVs or call transcripts?
- Can it see private data, such as CRM, billing or applicant records?
- Can it send or change something, such as an email, a Slack message or a CRM field?
Three yeses is the lethal trifecta, and IT will ask the next question first. Check a routine in 30 seconds.
The complete list of what it can do
- Can you list every action the tool can ever take, and every recipient it can reach?
- Do those come from code, or can the model choose them?
- If an email told the tool to send data somewhere else, what would stop it?
Whose access it uses
- Does each person sign in as themselves?
- Does the tool store any passwords or keys? (The best answer is no.)
- Can each person only see what they could already see without the tool?
What it can do on its own
- Does it only prepare drafts, or can it send and change things?
- If it can send, who decides who is allowed to?
Records and switching off
- Is there a record of every action, with the person’s name?
- How do you switch it off for one person? For everyone?
- What happens when someone leaves the company?
If some answers are “I don’t know” or “it uses my login”, use them to scope the next review. Native controls may already solve the problem. Cresec can be evaluated for a specific supported gap; integration work and an ongoing owner are still required. Check the FAQ.
Sources and further reading
- Lovable: project access and published website access
Editor access and access to the published app are separate settings. Check both before inviting a teammate.
- Retool: permission groups and access rules
A worked example separates app users, developers and administrators. Use it to frame the permissions your existing platform can provide.
- Claude: custom remote MCP connectors and trust considerations
A custom connector grants access to an external service. Review its operator, requested permissions and data handling; connecting is not a security assessment.