Six questions to settle before AI touches your workflow

I'm building an AI integration for a regulated financial services firm at the moment. The model work was the easy part. These six questions took the time, and they apply to any business.

A wooden desk with a keyboard, mouse, coffee mug, documents, and pen, with a wall-mounted cabinet above and a window to the left.

In short

Before AI touches a workflow, settle six things: what identity the tool acts as and therefore which files it can surface, where data is processed and whether your inputs train someone else's model, which model version you depend on, what gets logged, who reviews output before a client sees it, and what it costs at full usage rather than pilot volume.

I'm working on an AI integration for a regulated financial services firm at the moment, built on Azure AI Foundry. The model work has been the straightforward part. What took the time was a set of six questions that had little to do with machine learning, and every one of them would land the same way at a dental practice, an accountancy firm or a distributor.

If someone is asking you to put AI into how your team works, settle these before anyone writes a line of code.

What identity does the AI act as?

This is the question that catches people, and it is worth understanding before any of the others.

An assistant grounded on your own documents has no separate view of your files. It answers as the person asking. So it can surface anything that user already has permission to open, including the folder nobody has looked at since 2019 with an old payroll spreadsheet in it.

Nothing has been breached. The permissions were always that way. What changes is that finding the file no longer depends on knowing it exists.

An AI rollout is a permissions audit with a better budget attached. Run the audit first. Who can open what, which shared drives inherited permissions from a structure that stopped making sense years ago, and which leavers still have access. You will find things. Every business does.

Where the data sits, and whether you can prove it

Two separate questions hide inside "is our data safe".

The first is whether your inputs are used to improve someone else's model. The second is which country the processing happens in, and where anything stored comes to rest.

Both are answerable, and both are configuration choices rather than matters of faith. Microsoft publishes what Azure OpenAI does with prompts and outputs, and the deployment region is yours to choose. The point is not which vendor you pick. It is that you should be able to state the answer and point at where it is written down.

Ask your provider for that in writing. If they cannot produce it, you have your answer.

The model underneath you will change

A workflow you build today sits on a model version with a retirement date. Providers deprecate versions on a published schedule, and the replacement does not behave identically. Prompts that produced clean output can drift.

This is ordinary software maintenance, and it surprises people who expected to buy AI once. Budget for revisiting the work twice a year. Write down which model version each workflow depends on, so that when a deprecation notice arrives you know what it touches. The Azure AI Foundry documentation publishes those schedules, and the same applies whichever platform you build on.

Nobody can tell you what it did six months ago, unless you logged it

If an AI tool drafts a client letter or classifies an invoice, someone will eventually ask what it was given and what it produced. A client, an auditor, or you, working out how a mistake got out the door.

You cannot reconstruct that after the fact. Either the prompt, the response, the user and the timestamp were written to a log at the time, or the event is gone.

Decide up front what you retain, for how long, and who can read it. The log holds client data, so it needs the same protection as the system it watches.

Who owns the answer when it is wrong

Treat AI output as a draft from a colleague who is confident and occasionally wrong.

Name the human who checks it before it reaches a client, and put that step in the process rather than in a training session. A step that lives in someone's memory is not a step.

For anything going out under a professional's name, the review has to be real. If checking the output takes as long as writing it from scratch, you have picked the wrong task to automate. That is useful information, not a failure.

What it costs once the whole team uses it

Pilot costs and production costs are different numbers.

Usage-based pricing means the bill scales with how much your team uses the thing, which is the outcome you wanted. Model the cost at full adoption rather than at pilot volume, and set a spending alert on the subscription on day one.

The larger cost sits elsewhere. Integration, permission cleanup, logging and review time are where the effort goes. The tool licence is the small line on that invoice.

Where to start

Pick one workflow that annoys people and does not touch clients. Internal document search, drafting standard replies, sorting inbound post. Run the permissions audit before you connect anything to it. Log everything from the first day. Name the reviewer.

That is enough to find out whether AI helps your business before it goes near anything that matters.

If you want a second opinion on which workflow to start with, or on the permissions sitting underneath it, that is the ground we cover in our business automation work and in the quarterly sessions of the Technology Success Program. It comes up early with financial services firms, where the audit trail question arrives on day one.

Can staff see files through an AI tool that they could not see before?

Not files they had no rights to. An assistant grounded on your documents answers as the person asking, so it inherits their permissions. What changes is discovery. A file someone could technically open but never knew existed becomes findable in one question. Run a permissions review across shared drives and mailboxes before you connect anything to them.

Do we need a written AI policy before we start building anything?

A policy helps, but it is the second step. Start by finding out what your team already uses and what your files actually permit. A policy written before that is guesswork. Once you know the ground truth, a one-page note covering approved tools, what may be entered and who reviews output is enough for most small teams.

How do we prove what an AI tool was asked and what it answered?

Only if you logged it at the time. The prompt, the response, the user and the timestamp need writing to a durable log as the event happens, because nothing reconstructs it afterwards. Decide retention length and who can read the log before you launch. Treat the log as client data, because it contains client data.

What happens when the model our workflow depends on is retired?

Providers retire model versions on a published schedule, and the replacement behaves differently. Output that was consistent can drift. Record which model version each workflow depends on, so a deprecation notice tells you exactly what it touches. Plan on reviewing prompts and output quality about twice a year rather than treating the build as finished.

Is building on Azure AI Foundry different from switching on Copilot?

Yes. Copilot is a product you switch on and configure inside Microsoft 365. Azure AI Foundry is a platform for building something specific, where you choose the model, the region, the data it can reach and what you log. Foundry gives more control and asks for more decisions in return.

All blog posts

Start with a free IT review.

You'll get a clear picture of where you're exposed today, and what it looks like to have your whole IT covered as one managed system. No obligation.