Banks can deploy AI agents without giving up control of sensitive information by controlling four layers: where data is captured, where AI models process it, where the resulting information is stored, and who is permitted to retrieve it. The right architecture depends on the sensitivity of the information and the institution's willingness to operate technology itself.
Capture → Model → Storage → Permissions
The most valuable information is the most sensitive
The information an AI agent could use best is usually the information a financial institution guards most closely. Credit committee debates, client financing discussions, risk reviews and internal strategy sessions hold the reasoning behind a firm's decisions. They also hold confidential client information, investment views and material business decisions.
For most of my career, working with that kind of information meant working inside clear boundaries: who could attend which meetings, who could see which files, and which parts of the firm had to stay separated by information barriers. AI agents do not remove those boundaries. They make them more important, because an agent can move information faster and further than any person.
Financial institutions already operate within extensive requirements governing the retention, supervision, access and protection of communications and client information. The question is not whether those obligations apply to AI. It is how to design an AI deployment so the firm can still meet them.
I find it useful to break that design into four layers.
The four layers of control
1. Capture: who is collecting the information?
Every AI workflow starts with something being recorded, transcribed or uploaded. In a client meeting, that might be a note-taking bot joining the call.
The capture point matters more than it first appears. When a client is walking a banker through a financing, they are sharing everything. A bot that belongs to an outside software company is an awkward presence in that conversation. A bot that belongs to the bank, operating like the banker's own assistant, is a different proposition. In my conversation with Dmitry Grankin, founder of the open-source meeting platform Vexa, that distinction came up directly: the difference between a vendor's bot and "our bot" (12:40).
2. Model: where does the AI actually read the data?
Once information is captured, an AI model processes it: it transcribes, summarizes, extracts or answers questions. The critical question is whose computers that model runs on.
Sending a transcript to an external AI service may be acceptable for routine material. For sensitive conversations, many institutions will want the model to run inside their own environment. That is more practical than it used to be. Dmitry described a European bank customer that self-hosts its own language models (13:04), and observed that banks already run open-source transcription models and the underlying infrastructure in-house (13:57).
3. Storage: where does the result live?
Emails, documents and transaction records each have an established home inside a financial institution, with retention and access rules attached. Meeting data and AI-generated knowledge often do not. As Dmitry put it, meeting data "doesn't have its own place" (01:59). Transcripts end up in a vendor's cloud, a personal folder, or a CRM note.
If the firm does not decide where AI outputs are stored, the tools will decide for it. The goal is a defined, firm-controlled home for this information, with the ability to retain it as required and delete it when appropriate.
4. Permissions: who is allowed to retrieve it?
This is the layer that matters most once AI agents start retrieving information on someone's behalf.
Knowledge inside a firm naturally has layers. Some is meant for everyone, some for a team or a recurring committee, and some for one person. Dmitry described exactly this structure of company-wide, group and individual knowledge (01:59).
The rule I would apply is simple: an AI agent should only be able to retrieve what the person it is working for is allowed to see. Imagine an agent preparing a banker for a credit committee. It is enormously valuable if it can pull the relevant reasoning from prior committee discussions. It is a serious problem if it can pull discussions from the other side of an information barrier.
Three ways to deploy
Institutions can choose different levels of control, and the right choice can differ by use case.
Rent a vendor's cloud service. This is fastest to start and requires the least internal effort. The firm relies on the vendor's controls for capture, model processing and storage. It is best suited to less sensitive information.
Self-host software that a vendor supports. The software runs inside the firm's own environment, while a vendor maintains it and provides the necessary assurances. Dmitry framed the tension well: a bank wants to own the software, "but you don't want to babysit it" (08:49). This model keeps sensitive data inside the firm without requiring the firm to become a software company.
Run it fully in-house, including air-gapped. Air-gapped means cut off from the outside internet. Every layer, including the AI models, runs on the firm's own infrastructure (12:19). This gives the most control and requires the most internal capability.
Open-source software makes the second and third models more realistic, because the firm can inspect the code, run it where it chooses and avoid depending entirely on one vendor's roadmap.
Eight questions to ask before deploying an AI agent
- Who captures the information, and does the bot or tool clearly identify itself as ours?
- Where does the AI model run, and does any sensitive data leave our environment?
- Is the vendor allowed to use our data to train or improve its models?
- Where are the raw recordings, transcripts and AI outputs stored?
- Can we retain this information as our obligations require, and delete it when we should?
- Does the agent respect the same access rules and information barriers as our people?
- Can we see what the agent retrieved, and for whom?
- If we change vendors, can we take our data and our AI-generated knowledge with us?
If a proposed deployment cannot answer these clearly, it is not ready for sensitive information.
Where this is heading
Most institutions are still early. As Dmitry described it, many firms are building their own approaches now, and a smaller number of industry standards are likely to emerge over the next several years (13:57).
The firms that get the four layers right will be able to turn their internal conversations and documents into usable institutional knowledge, safely. That could be a meaningful advantage. But the decisions themselves stay with people. Dmitry closed our conversation on exactly that point: "We cannot automate human responsibility, human authority."
About the author
Michael McLaughlin has more than 30 years in structured finance and private credit. At Macquarie Group from 2008 to 2023, he built the credit markets business from inception into a portfolio financing platform that averaged a $5 billion portfolio and generated more than $1 billion in cumulative net revenue. He has advised Hebbia on AI research software for financial services, and builds his own finance applications with AI coding tools and open-source software.
Through Path66, Michael works with financial institutions and investment firms on asset finance, liquidity, capital raising, data-driven due diligence and the practical application of emerging technology in finance. He hosts Stack to Street, where he interviews the developers building the software that will change financial institutions. Full bio.
Source
Your Firm's Most Valuable Data Is Trapped in Meetings, Stack to Street with Dmitry Grankin, founder of Vexa. Full transcript on the episode page.