Key Takeaways
- IT evaluates risk, and anything unknown defaults to high risk—reduce unknowns by gathering security documentation (SOC 2, DPA) before your first conversation
- Frame requests around the business problem, not the tool—"We spend 30 hours/week on X" is more compelling than "We found a cool AI tool"
- Propose a limited pilot with clear exit criteria to contain risk and make approval easier
You found an AI tool that could save your team hours every week. You're excited. You mention it to IT.
Three weeks later, you're still waiting to hear back. Or you've received a security questionnaire with 47 questions, half of which you don't understand. Or someone mentioned the "procurement committee," and your heart sank because you know that means months.
Meanwhile, you're pretty sure at least a few people on your team are already using ChatGPT on their phones to get work done, because the official path is too slow. This shadow AI creates risks that IT is right to worry about.
Here's the thing: IT isn't your enemy. They're not trying to block progress. They're dealing with a real problem—every new tool that touches company data creates risk, and they're the ones who get blamed when something goes wrong.
The security questionnaire isn't bureaucracy for its own sake. It's because they've seen what happens when someone brings in a tool that leaks data or creates a compliance nightmare.
The trick isn't to fight IT or go around them. It's to make their job easier.
Reducing the Unknowns
The first thing to realize is that IT evaluates risk, and anything unknown is high risk by default.
When you come to them with a tool they've never heard of, from a vendor they don't know, asking for access to systems they're responsible for protecting—you're basically asking them to take on risk so that your team can be more productive. That's not a trade they're excited about.
But if you can reduce the unknowns before you even have the conversation, everything changes.
Before you schedule a meeting, do the homework. Go to the vendor's website and find their security page. Download their SOC 2 report if they have one. Get the data processing agreement. Read their privacy policy—actually read it, don't just skim it.
Figure out where the data goes when someone uses the tool. Find out if it's used to train their AI model (huge red flag for most IT teams) or if customer data stays isolated.
When you walk into the conversation already knowing this stuff, you've just saved IT hours of research. You've also signaled that you take security seriously, which matters more than you might think.
Framing the Request
How you frame the request makes a huge difference.
Don't lead with the tool. Lead with the problem.
"Our team spends 30 hours a week answering the same benefits questions over and over. I've been looking for ways to solve this, and I found something that might work."
Now IT understands why you're asking. It's not "HR found a shiny toy and wants to play with it." It's "HR has a real business problem and found a potential solution." This same problem-first approach works when building your business case for the CFO.
Then, before they can ask about security, address it yourself. "I know data security is the first question, so I pulled their documentation. They have SOC 2 Type II, they don't train on customer data, and they can do data residency in Canada. Can I send you what I found?"
You've just skipped three weeks of back-and-forth.
Start Small to Win Big
The other thing that helps is making the ask small.
"I want to pilot this with 10 people for 60 days" is a much easier yes than "I want to roll this out to the whole company."
A limited pilot contains the risk. If something goes wrong, the blast radius is small. And if the pilot works, you've got evidence for the broader rollout.
Define the Exit Strategy: Offer to own the administrative stuff during the pilot. "I'll manage access and be the point person if anything comes up—you won't have to support this directly." IT teams are stretched thin. Anything you can take off their plate makes approval more likely.
Make sure there's a clear exit. "If it doesn't work or there are any issues, we can shut it down immediately. No long-term contract, no data lock-in." Knowing they can reverse the decision makes IT much more comfortable making it.
What IT Actually Looks For
Some tools are just easier to approve than others, and it's worth knowing what IT looks for.
Content isolation: They're more comfortable with tools that answer only from your own content—your policies, your documents, your knowledge base—than tools that pull from the open internet or general AI training data. If they know exactly what information the AI can access, the risk profile is clearer.
Explicit data commitments: They like explicit data commitments. "Your data is never used for training" is easy to evaluate. Vague statements about "taking privacy seriously" are not. This is also where AI governance policies help establish organizational standards.
Admin controls: They want admin controls—the ability to see who's using the tool, what they're doing with it, and to revoke access if needed. Audit logs matter. Role-based permissions matter. If the vendor can't show these features, IT gets nervous.
Vendor stability: They also care about vendor stability. A tool from an established company with real customers and a track record is easier to approve than something from a startup that might not exist next year. That might not be fair to scrappy startups, but IT is thinking about what happens to your data if the vendor disappears.
If you're still evaluating options, weigh these factors. Picking a tool that checks IT's boxes from the start saves weeks of back-and-forth. Look for solutions designed for enterprise needs—like knowledge assistants that answer from your own content.
What to Avoid
A few things that don't work, in case you're tempted:
Going around IT. Getting people to sign up with personal emails, expensing it on a corporate card without approval, quietly using it, and hoping no one notices. IT always finds out eventually, and when they do, you've torched your credibility. The tool gets shut down, and every future request starts in a hole.
Manufacturing urgency. "We need this approved by Friday, or we'll miss a huge opportunity." IT has heard this before. It's almost never actually true. Fake urgency makes them trust you less.
Downplaying security concerns. "Oh, it's totally fine, don't worry about it." You're not the expert here. When you dismiss their concerns, they assume you haven't done your homework.
Escalating to force it through. Getting a VP to pressure IT into approval might work once. But you've made an enemy, and your next request—and the one after that—will be harder.
The Long Game
Here's the thing nobody tells you: the real goal isn't getting this one tool approved. It's building a relationship with IT so that future requests are easier.
When your pilot succeeds, tell them. Share the results. Thank them for working with you. When you notice something concerning—a security issue, an unexpected behavior—bring it to IT proactively instead of hiding it. Be the person who takes this stuff seriously.
Over time, you become someone IT trusts. Your requests move faster. Your judgment carries weight. You become the person other teams come to when they want to bring in something new.
That reputation is worth more than any single approval.
Choose Tools Built for Enterprise
One more thing. The fastest path through all of this is to pick tools that were built for enterprise from the start.
The vendors who understand enterprise sales have already done the security work. They have the SOC 2 report ready to send. They've built the admin controls IT needs. They know how to run a pilot that makes approval easy. They've been through this conversation hundreds of times. And they offer transparent pricing that helps you budget appropriately.
When you bring IT a tool like that, everything is smoother. The documentation exists. The answers are clear. The vendor knows how to work with IT instead of against them.
Which means you spend less time in procurement limbo and more time actually solving the problem you cared about in the first place.
JoySuite is built for exactly this situation. SOC 2 Type II certified. Your data is never used for training. Full audit logs and admin controls IT will actually like. And we're happy to get on a call with your security team—we've done hundreds of them. Get the security documentation your IT team needs.
