Getting IT approval for AI workflows: step-by-step guide

Phase 1: Scope

Every engagement starts with a scope form we provide. It names the trigger, the systems the workflow touches, and the output, so the start and the end of the workflow are written down before anything is built.

Nothing outside the form gets built, and the testing phase measures against exactly what it says. If the scope needs to grow, it grows through the form.

The worked example

The example used throughout this page is a tender agent we built for a UK construction contractor. It does one thing: when someone forwards it an invitation to tender, it works out which of the company’s past proposals are closest to the new opportunity, and answers with that shortlist where the bid manager can act on it.

That is five steps:

1. 1.A tender arrives by email, with the documents attached.
2. 2.A person on the team forwards it to the agent, or mentions the agent from Outlook. The agent reads the covering note and the attachments. Nothing watches anyone's inbox.
3. 3.A language model works out what the tender is: the buying authority, the region, the phase, the type of work, the value band, whether the site stays occupied, the return date and the award weightings.
4. 4.The agent reads the company's past-proposal library out of one document library.
5. 5.It answers once, as a reply in the sender's inbox and as a new thread in the team's channel: the three closest past proposals, each a link plus a one-line reason, and it asks which one to build the response on. It drafts nothing until a person picks.

From your IT team’s point of view that is four kinds of traffic: one mailbox read, which is the agent’s own, one document library read, one outbound HTTPS call to a model API, and one channel written to. Nothing else: no inbound connection, no software on anybody’s laptop, and no access to a user’s personal files. Every workflow we build has those same four parts, so the scope form mostly names which systems fill them.

Phase 2: Access

On this route we host the workflow, and today it runs on Microsoft 365 and Teams. Your IT team’s part is roughly fifteen minutes of administrator work: three short steps, plus up to three optional ones depending on what the workflow touches.

What your IT team does

1. 1.Grant admin consent (about one minute, Global Administrator). The consent screen lists exactly one permission of ours, which Microsoft prints as "Access selected site collections". It grants nothing by itself: no site in your tenant answers until you name one in the optional library step below, and nothing on the screen touches mail or messages.
2. 2.Install the Teams app (about three minutes). You upload our app package in the Teams admin centre and add it to the team you choose from the Teams client. The team owner approves it reading and sending channel messages in that team only. The agent answers when it is mentioned, when someone replies in a thread it already holds, or when an approval card is clicked. Every other post in the channel is ignored.
3. 3.Name your approvers (about one minute). You tell us which people may approve gated actions. The same people can tell the agent to stop at any time, and start it again.

Three optional steps

Each applies only if the workflow uses that capability.

• Email (a couple of minutes per address, Exchange administrator). You add a mail contact that points at the agent's own external address, so your people can mention it from Outlook. There is no consent and no grant in your directory. The agent answers mail only from the sender domains, and the individually named addresses, that you have approved. Everything else is refused without entering the workflow, and each refusal is recorded so we can report it to you.
• A document library (about five minutes, SharePoint Administrator on a call with us). One call grants the agent read access to one named site. Every other site in your tenant still refuses it, and it cannot list or search your sites to find more. You can take the grant away at any time, on your own, and nothing else needs undoing.
• A rehearsal (about five minutes). Before the agent speaks to your team, it runs for a few days with everything it would have said going to a private team that only your IT contact and the project owner can see. In that mode it sends no email and says nothing in your live channels, apart from answering a named approver who tells it to stop or resume.

Where it runs, and where data flows

The workflow runs in our cloud, operated by us. Your data passes through our systems on its way to the model API and back. That is the trade against the other route: less work for your IT team, and data that moves through infrastructure we operate.

Four properties bound that trade. Each client gets its own dedicated app identity and bot, never shared with another client. Each client’s stack runs isolated from every other client’s, with its own encrypted storage. The agent’s activity records hold identifiers, digests, counts and decisions: who asked, who approved, and who was refused. Message content and document content are never written to our logs. And data is deleted on a fixed retention schedule that we put in writing for each client.

Email, if the workflow uses it

The agent has its own address on our domain, so mail to it lands in a mailbox in our tenant, and its replies to your people come from our domain, with sender authentication set up on our side. No mailbox of yours is read, and none is granted. Your IT team may need to allow sending to that one external address, and attachments past any data-loss-prevention rules on outbound mail. The onboarding pack we send flags both.

The model account

We run the workflow on our Anthropic business plan. Anthropic does not train models on data from business plans, and it retains that data for a limited window measured in days. We put the exact current terms in writing at the scope call rather than paraphrase them here.

This is the same kind of processing your organization already accepts if it uses Microsoft Copilot or Claude at work: content goes to a model provider that does not train on it, comes back as output, and is deleted on a schedule. What we add is the automation around it.

Your security review

Your security team may need to approve us as a third-party provider before this route is allowed, and every organization draws that line differently. We work through your security requirements with you before anything runs. If that review rules this route out, the in-your-tenant route still works, because there the data never leaves your tenant.

Phase 3: Testing

We run the testing phase ourselves, on both routes. Model and API usage during testing is billed at cost, with no margin. It is a small amount, and it exists only to confirm the workflow behaves.

Testing has one exit condition: the workflow agreed in the scope form runs end to end on its own and gets the right answer. When it does, testing is over and the workflow goes live.

Phase 4: Aftercare

Maintenance is £1,000 per year. It covers fixes to the workflow for as long as the fee is paid, under the service levels below.

On our key, you get one invoice and no procurement. We run the workflow on our key, set a usage cap, alert on unusual volume, and invoice the usage at cost each month, next to the maintenance fee. This suits teams that do not have an AI vendor relationship yet and do not want to create one for a single workflow. Moving to your own key later is one rotation.