Secure AI deployment for fund administrators
By Kumar Ujjwal, Founder and CEO, DwellFi
"We can't use AI, our data is too sensitive." We hear this all the time.
It comes from fund administrators, sovereign wealth funds, family offices and the instinct behind it is correct. The conclusion isn't.
The objection assumes AI has to mean your data leaving your building and landing on someone else's servers. That was true in 2023. It stopped being true once vendors started building for regulated institutions instead of retrofitting consumer tools for them.
Secure AI deployment now means the model runs inside your perimeter and on your cloud tenant. Your air-gapped network and your own rack in your own data center. The data doesn't travel anywhere. The model doesn't learn from it. Every query gets logged, every user gets authenticated, and every output can be traced back to who asked for it and why.
For an administrator holding data it is legally barred from exposing, that distinction is the whole conversation.
The vendor problem, not the AI problem
Most AI products are built on one architectural assumption: your data goes to the provider's cloud to get processed. Fine for a marketing team drafting ad copy. A dealbreaker for a fund administrator whose custody agreements don't allow that data to exist anywhere outside a defined boundary.
The hesitation you've heard from compliance isn't caution for its own sake. It's a correct read of how most of these products are wired.
Vendors optimizing for scale build one way. Institutions optimizing for control need something else built entirely.
What "runs inside your environment" actually means
The intelligence moves to where your data already sits. Not the other way around.
In practice, that looks like this. The data stays inside your perimeter for the full life of the query. The model never trains on anything you feed it. Every request is authenticated against your existing identity system. Every output can be pulled up later with a timestamp and a name attached. You keep custody of the data the entire time, full stop.
Three ways to deploy, depending on how sensitive "sensitive" is
Diagram of three AI deployment models (in-tenant cloud, air-gapped, on-premises), each contained within a "your perimeter, data never leaves it" boundary, with isolation levels marked for each.
Not every fund needs the same wall around its data. Three options cover most cases.
- In-tenant cloud. The AI runs inside your own AWS account, Azure tenant, or GCP project. Nothing leaves your infrastructure. Access runs through the IAM system you already have. This is the right fit for most regulated institutions: cloud flexibility with the residency guarantees compliance needs signed off on.
- Air-gapped. The model runs on a network with zero external connectivity. No internet path in or out. This is what sovereign funds and institutions with a zero-tolerance breach policy tend to ask for, and it's the highest floor available.
- On-premises. Your hardware, your data center, your stack from top to bottom. Makes sense if you already run infrastructure this way and have the team to operate it.
Different levels of isolation. Same rule underneath all three: the data stays where it started, and you stay in control of it.
How the access controls actually hold up
Security here isn't a layer added on at the end. It's the constraint the whole system gets built around.
Single sign-on means your identity provider decides who's allowed in, not a separate login the vendor manages. Role-based permissions control access down to the folder and document level. Multi-factor authentication is required on every session, no exceptions. And every query, every output, every access event gets logged with a timestamp and the user's identity attached to it.
That's what lets you answer "who saw this, and when" without guessing. It's also what a real security review is actually checking for, not a checkbox on a vendor's compliance page.
Build for the buyer who can't afford to be wrong
Here's the pattern that separates vendors that survive a due diligence process from ones that don't: the institution with the least tolerance for failure ends up setting the standard everyone else inherits.
Design an architecture that passes a sovereign fund's security review, and a mid-market administrator gets that same architecture by default, without asking for it. The strictest requirement in the room becomes the floor for every deal after it.
That's the reasoning behind how DwellFi built this. Not because the hardest customers were the easiest to land. Because solving for them meant the solution already worked for everyone downstream.
Frequently asked questions about secure AI deployment for fund administrators
Have more questions about fund operations? We got them answered:
Does the AI train on our data?
No. In an in-environment deployment, the model doesn't train on customer data and the data never leaves your perimeter. It isn't used to improve the model or any future version of it.
Can it run fully on-prem or air-gapped?
Yes, both are available deployment paths. Confirm the specifics with your vendor directly. Not every vendor supports all three models, and requirements vary by institution.
What certifications apply?
Ask the vendor for current certifications (SOC 2, ISO 27001, and so on) directly. Any certification claim belongs in your security review, not in place of one.
How do I know the vendor isn't just saying the right things about data residency?
Ask for the audit logs. Ask to see the actual controls, not a slide describing them. A vendor confident in its architecture will hand these over without friction. One that stalls is telling you something worth paying attention to.
Does in-environment deployment slow anything down?
Barely, if at all. The model performs the same whether it's running in your cloud or on your own hardware. You aren't giving up capability to get security. You get both.
Bring it into your next vendor call and ask the questions yourself. See the audit logs, the controls and how this actually runs in practice.