How to Run AI Discovery for a Regulated Client

Discovery in a regulated environment works differently: the constraints eliminate more options than the opportunities create, so establishing them first saves weeks. This playbook covers running one that produces a scope surviving review, drawing on FISTA Solutions' forward deployed engineers work. This article is general guidance, not legal advice.

When is this worth doing?

At the start of any engagement with a client in financial services, healthcare, government, insurance, or another supervised sector.

It is also worth doing inside such an organisation before committing to an internal programme, because the constraints are the same regardless of who is delivering.

What does the sequence look like?

Step	Purpose
1. Establish the obligations	Which regimes and what they require
2. Map data access reality	Where, how, and how long it takes
3. Identify the approvers	Security, privacy, business, regulatory
4. Find candidate workflows	Within the constraints, not despite them
5. Scope to what survives review	Narrow and defensible
6. Produce a realistic timeline	Including approval time

Step 1 — Establish the obligations first

Ask which regulatory regimes apply to the client and to the specific process, what their supervisor has published, and what internal policy adds.

Those answers eliminate options quickly. A process where decisions must be explained rules out opaque approaches; one where data cannot leave a jurisdiction rules out most external model services.

Do this in the first week. Discovery that surfaces obligations in week six has usually produced six weeks of work against an architecture that will not be approved.

Step 2 — Map the data access reality

Find out where relevant data lives, who owns it, what is required to access it, and how long that takes in practice rather than in policy.

In most regulated organisations this is measured in weeks. Discovery that assumes same-week access to representative data produces plans that slip at the first milestone, and the slip is attributed to the delivery team.

Start the access request in week one, even before knowing exactly what you need. The lead time is the constraint, not the specificity.

Step 3 — Identify everyone who must approve

Security, data protection, the business owner, and frequently a model risk, compliance, or regulator-facing function.

The number is usually higher than the sponsor states, and discovering an approver in month three is the most common cause of a stalled engagement. Ask directly: who else signs this off, and what do they need to see.

Meet them during discovery rather than presenting to them at the end. Their constraints become design inputs instead of late objections.

Step 4 — Find candidate workflows within the constraints

Look for workflows with measurable current cost that can operate inside what the constraints allow.

In practice this favours document handling, internal knowledge retrieval, triage, and preparation work over anything making a regulated decision. That is not a limitation to work around; it is where the value is available soonest.

Be explicit about what is excluded and why. A client who understands the reasoning accepts a narrower scope; one who feels their ambition was quietly reduced does not.

Step 5 — Scope to what survives review

Choose the first system for defensibility as well as value: clear boundaries, human decision points preserved, evidence produced by design, and data handling that matches the constraints.

A narrower system that is approved and running beats a broader one in review for six months. It also builds the relationship and the evidence that makes the second scope easier.

Write the scope with the approvers' questions in mind. Proposals structured as answers to those questions move considerably faster.

Step 6 — Produce a realistic timeline

Include the approval time, the data access time, and the security review time as explicit line items rather than assuming them away.

Timelines that show only delivery effort are the standard cause of disappointment in regulated engagements, and the disappointment lands on the delivery team even though the delay was procedural.

Showing those items also makes them visible to the sponsor, who is frequently the only person who can shorten them.

What if the client cannot use external model services?

Then the options are self-hosted models inside their environment, an approved provider with the required certifications, or a design where no controlled data reaches the model.

All three are workable and they have different cost and capability profiles. Establishing which applies in week one prevents designing around an option that is not available. See what is an air-gapped AI deployment.

How do you handle a sponsor who wants more ambition?

By showing the sequence rather than refusing the ambition.

The narrower first system is not the end state; it is the fastest route to evidence that makes the larger scope approvable. Framing it that way keeps the sponsor engaged and sets up the second phase.

What does not work is agreeing to the larger scope and discovering the constraints later, which costs the relationship as well as the time.

Who needs to be involved?

Someone who can talk to security and compliance credibly, someone who understands the business process, and a technical lead who can assess feasibility within constraints.

Discovery run by technologists alone produces proposals that fail review. Discovery run by consultants alone produces proposals that cannot be built.

How long does it take?

Three to six weeks in most regulated environments, dominated by data access and approver availability rather than by analysis.

What are the common failure modes?

Scoping opportunities before constraints. Assuming fast data access. Discovering approvers late. Proposing architectures the client cannot use. And timelines that omit approval time.

How do you know it worked?

A scope the approvers have already seen and accepted, data access underway, a timeline the sponsor believes, and a first system that can actually be built.

What does it cost?

Mostly people's time rather than tooling. The expensive version is the one that stalls halfway and leaves the organisation with neither the old state nor the new one, which is why a narrow first pass beats a comprehensive plan nobody finishes.

Budget the work as an operated change rather than a project with an end date, because most of these need a maintenance tail. See AI total cost of ownership.

What should you do first?

Ask which regulatory obligations apply to the process and where data may be processed. Those two answers eliminate most of the design space before anyone draws anything.

How FISTA Solutions helps

FISTA Solutions runs this work alongside client teams rather than around them: constraints and approvers established in the first week rather than discovered later, scope chosen for defensibility as well as value, evidence produced as the work proceeds, and handover that leaves your people able to continue without us. Delivery runs through AI agents, AI enablement, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries, with 47% average efficiency gains where measured.

To run this with support, message FISTA on WhatsApp, or read how to scope an AI agent project.