How to Build AI Inside a Regulated Firm's Own Cloud

Early this year I was on a call with the head of technology at a wealth management firm with several hundred advisors. He called his the most highly regulated industry there is, and then he listed why: the records the firm is required to keep, and the personal information it holds on every client.

Around the same time, their security team had looked at how we normally build and said no.

How we normally build is fast. Workflows run on an automation server we stand up, a small database sits alongside, and the models are called from there. For a firm of a few dozen people that is a good answer. It is cheap, it ships in a week, and the client owns the server.

For this firm it would have meant client data travelling to infrastructure their security team had not reviewed and did not run. So nothing was built that way. They were right to refuse, and I would much rather hear that in the first month than the sixth.

The work moved inside the firm's own cloud environment. Everything since has been built there.

Build where the data already lives

A regulated firm has usually spent years deciding where its data may sit. Identity. Access. Encryption keys. Logging. Which region. Who can read which client. That work is done or well underway, and it belongs to them.

When you bring your own stack, you are asking them to do all of it a second time, for you, on infrastructure they do not control. When you build inside theirs, you inherit it.

For this firm the design looks like this. The data comes from the lakehouse their own data team was already building. The agents run in their cloud. The models are called through the firm's account, so the firm holds the keys and pays the bill directly, and we bring no keys of our own for anything in production. Secrets sit in their vault. Our engineers sign in with identities the firm issues and can switch off.

There is a second benefit nobody puts on a slide. If the engagement ever ends, there is nothing to migrate and nothing to hand back. The system was never ours.

The security team is a design input

The usual sequence goes like this. The business asks for something. A vendor builds it. In the last two weeks, somebody sends it to security. Security finds three problems, the launch slips, and everyone quietly concludes that security is the obstacle.

The obstacle is the sequence.

In a regulated firm, security decides the shape of the system. Which way data may flow. Who may see which client. What gets logged and for how long. Those are architecture decisions. If they arrive at the end, you rebuild. If they arrive at the start, they are simply the spec.

So we changed the order. When the firm ran its architecture workshop in May, the technology team gave a whole session to their standards, access protocols, deployment environment and security requirements, and it came before the session on what we would build first. We designed to that.

One principle we put to them in writing before the workshop, and asked them to confirm: data flows one way, from the systems of record into the lakehouse, and any exception is written down and tightly bounded. That rule makes the system easier to reason about. It also makes it far easier for a security reviewer to approve, because there are fewer doors to check.

What it costs

It is slower at the start, and I should say so plainly.

Access took weeks, not days. Every engineer needs an identity, a machine the firm trusts, and permissions granted one system at a time. That is what a well-defended environment looks like from the outside, and it is how it should be. By April I was asking the firm for laptops and a development environment, so that the build team could work inside their standards from the first morning rather than learn them later.

Some of our usual tools are not available. We use what the firm has approved, and anything new goes through their review like any other request.

None of that time is wasted. Every week spent on access is a week the security team never has to spend at the end, pulling apart something already built. By the start of June a development environment for the advisor portal was running inside their cloud. The build team starts at the end of this month, on ground the security team has already seen.

Three questions before you sign

If you run a regulated business and you are about to hire someone to build with AI, ask these first.

Where will our data be processed, by name, and whose account pays for the model calls? If the answer is the vendor's account, your data has gone somewhere.

Can the whole thing run inside our own cloud, with our identities and our key vault? If not, get the reason in writing.

When does our security team first see the design? The right answer is before there is one.

Then do one thing this week. Invite your security lead to the first working session, not the last. Give them the data flow on one page and ask what they would refuse. Whatever they say is the spec.