Two decisions sit behind every AI job, and they belong to different people. You decide whether the work is worth doing. Your IT partner decides whether it can run safely and whether anyone can support it on a wet Tuesday afternoon. Knowing when to involve your IT partner starts with keeping those two decisions apart.

The split that keeps this simple

You own the business question, and it has four parts. Which problem does the job solve? What does a correct output contain? Who reviews it, and does the money make sense?

Your IT partner owns the technical question, and that also has four parts. Where does your information go? What does the tool connect to? What happens when it breaks, and can they support it alongside everything else?

Trouble arrives when either side answers the other’s question. An IT partner picking the use case tends to choose whatever is easiest to install. A business owner might promise a live link into the accounts package before anyone has checked the permissions. That becomes somebody else’s problem to solve. Stay on your own side of the split and both conversations improve.

Four triggers that mean you involve your IT partner

With the split clear, the practical question is which jobs cross into their half. Most AI jobs sit quietly inside a browser, so they never do. Four things change that.

The first is a connection to a system you already run. Once a tool wants to reach your email, your file store, your CRM or your accounts package, somebody has to grant permissions. Permissions are firmly IT’s ground.

The second is the information going in. Personal data or client-confidential material raises questions about storage, contracts and who else can read it. The security question covers what happens to a document once you paste it in. Your IT partner will want that answer in writing rather than in a sales deck.

The third is buying at company level rather than trying a single seat. Admin accounts, shared logins and the process for removing someone all have to work before you roll anything out.

The fourth is output that moves on its own. If an answer goes straight to a customer, into a system or onto an invoice without a person reading it first, the risk changes completely.

What genuinely needs no technical conversation?

Plenty of useful AI work trips none of those triggers, and treating it as though it does will cost you goodwill.

A person using an approved tool in a browser needs no technical sign-off. They work on their own material, paste nothing confidential, and read everything before it counts. Drafting a reply, summarising a document that is already public, tidying meeting notes, rewriting a job advert: none of that needs a ticket.

Your policy covers this ground far better than a case-by-case decision does. Writing an AI use policy settles the everyday questions in one page, which frees your IT partner for the jobs that genuinely need them. Ask them for a technical opinion on everything and people quietly stop asking at all.

How to brief them properly

When you do involve your IT partner, the quality of your brief decides the quality of the answer you get back.

Bring the job rather than the product. Five lines usually cover it. Name what starts the work, what goes in and in what format, and what comes out. Then name who reviews it and what happens next. A brief like that lets them tell you which parts worry them. Otherwise they react to the product name, and most people have opinions about those already.

Then ask three questions and expect plain answers. Where does our information go? What does this connect to, and with what level of access? What do we do when it stops working? The NCSC guidance on AI and cyber security speaks to people making exactly this kind of decision. It gives you a fair guide to what a serious answer sounds like.

Give them your decision date and a rough budget too. Advice without those constraints tends to arrive as a list of everything that could possibly go wrong.

Test on a copy before a live connection

A good brief still leaves one question open, which is how the tool behaves on your actual material.

Answer it with a copy. Put real documents in a separate folder and point the tool at that. Include the awkward ones: the badly scanned invoice, the contract with handwritten notes, the file with an unhelpful name. Demos run on clean material, so they teach you almost nothing about your own.

Testing on a copy does two other things. It caps the damage if something goes wrong. It also shows what access the tool asks for, which is often wider than the job needs. Only after that test should you discuss a live connection, and then with the narrowest access that still does the work. Choosing an AI tool goes further into what a fair test looks like.

Agreeing support before you go live

Once the connection is agreed, settle the boring questions while everybody is still keen.

Who does somebody ring when the output stops arriving or starts looking wrong? Does this tool sit inside your existing support arrangement, or outside it at a different rate? How quickly will they respond? Ask those three, and write down the answers, because a tool nobody supports quietly becomes one person’s private project.

Settle the admin account as well. Someone in your business should hold it, with your IT partner named alongside, so a single leaver never takes the keys with them.

Agreeing how to switch it off

The same conversation should cover the ending, because every tool eventually has one.

Agree who can revoke access and how fast they can do it. Agree what happens to information the tool holds when you stop paying. Agree how the tool appears on your leaver checklist. Subscriptions bought outside the usual process rarely make that list, and old accounts with live connections carry real risk.

None of this takes long. A short exchange of emails covers it, and having it before you go live is far easier than arranging it during a bad week.

Bring them in while the job is still on paper

All of this is easier to agree at one point in the job than at any other.

Involve your IT partner at the description stage and they can shape the job, set conditions, and warn you about costs that never appear in a quote. After the contract is signed, the only thing left for them to do is tell you what you have taken on. So send them the five-line description of the job before you sign anything. That one email is what turns a technical opinion into advice you can still act on.