AI governance has to operate at runtime

Most financial advisory firms started their AI work in low-risk places.

An adviser uses ChatGPT to tighten an email. A paraplanner summarises a meeting transcript. Someone asks an internal tool to turn rough notes into a first draft of a file note. Those uses matter, but they don’t change how the firm runs.

The next stage is different. AI agents don’t just draft words. They gather data from systems, apply workflow rules, create records, request documents, route work to people, and prepare actions for approval.

That is where governance moves from a policy document to a runtime control problem.

The VentureBeat reporting on regulated industries getting to runtime AI governance first reflects what I see in the advisory market. Financial advice businesses can’t simply tell staff to “use AI responsibly” and assume that covers an agent accessing CRM records, portfolio data, client communications, and compliance templates.

The firm needs controls while the work is happening.

Before an agent is permitted near a client workflow, three things should be true:

1. A clearly identified person has approved the work at the appropriate point.
2. The agent has only the permissions required for that step.
3. Every material action is recorded in an audit trail that a manager or compliance team can review later.

This isn’t about making AI slow or bureaucratic. It’s about making useful automation safe enough to use on the work that consumes real time and real margin.

For a financial advisory business between $1 million and $25 million in annual revenue, the leakage tied to manual advice production, meeting administration, onboarding delays, and rework often sits in the $70,000 to $200,000 range each year. Not all of that is fixable with AI. A meaningful portion is caused by people repeatedly chasing information, re-keying data, and reviewing work that should have been controlled earlier.

Drafting tools are not agents

The distinction matters.

A drafting tool waits for a person to paste information into a prompt and decide what to do with the result. Its risk is largely contained by the user’s judgement, although confidentiality and quality still matter.

An agent operates across a defined workflow. It can receive a trigger, retrieve relevant records, assess what is missing, create a draft, request a human decision, and write approved information back to a system.

Consider a routine annual review.

A simple drafting tool might turn a transcript into meeting notes after the adviser manually exports the transcript and removes sensitive details.

A controlled agent can start when a review meeting is scheduled. It can retrieve the last review notes, current portfolio holdings, recent client communications, open service issues, stated goals, and upcoming advice requirements. It can assemble a one-page brief. After the meeting, it can produce draft file notes, flag follow-up tasks, and prepare a review package for a paraplanner or authorised representative.

That workflow is more valuable because it removes handoffs. It is also more exposed because the agent can touch records, make classifications, and prepare documents that affect a client relationship.

This is why a policy saying “all AI-generated content must be reviewed” isn’t enough. It doesn’t answer the operational questions:

• Which client records can the agent read?
• Can it see every household, or only the adviser’s assigned clients?
• Can it create a task, update a CRM field, or only prepare a proposed update?
• What happens when the transcript conflicts with an existing fact find?
• Who must approve a document before it enters a client file?
• Can a junior team member override an agent’s escalation?
• How long are prompts, outputs, approvals, and data-access records retained?

A firm that answers these questions after rolling out agents is doing risk management backwards.

The workflow where controls become real

Meeting preparation is a practical place to start because it has a clear boundary and immediate value.

Advisers commonly spend five to 10 hours each week preparing for reviews, recovering context after meetings, and writing up what happened. Some of that work is necessary professional judgement. A lot of it is administrative retrieval.

The Meeting Prep Agent in Omni ops is built for this part of the process. It pulls portfolio data, recent communications, open tasks, last meeting notes, and goal progress into a one-page briefing pack for the adviser to read before a client meeting.

Here is what a controlled version looks like end to end.

Before the agent runs

The system checks the meeting type, the adviser assigned to the client, and the client’s consent and communication preferences. It confirms that the agent is operating in the correct client household and is permitted to access the relevant systems.

It does not need access to every record in the CRM. It needs a narrowly scoped view of the client, their linked entities where appropriate, their advice history, and relevant workflow data.

This is permission limiting in practice. The agent should be able to read the source systems required to assemble a brief. It should not have blanket write access because it has no business need to change investment preferences, amend a risk profile, or send client instructions.

While the agent works

The agent retrieves the relevant records and creates a concise draft brief. It identifies missing information rather than inventing it. If an annual review record is overdue, it flags that. If the last recorded risk profile conflicts with a recent client message about changed circumstances, it marks the discrepancy for adviser review.

It should not infer a recommendation. It should not classify a client as having changed risk tolerance based on one loose statement. It can surface the issue and point the adviser to the source record.

Every system request, document retrieved, data field used, output generated, and exception raised should be timestamped. That is the audit trail.

The useful question is not, “Can we see the final brief?” It is, “Can we show how the brief was assembled and what data it used?” If a client, licensee, or compliance reviewer asks six months later, your team needs an answer without reconstructing the story from inboxes.

Before anything changes

For a meeting brief, the approval can be lightweight. The adviser reviews it in the workflow, accepts it, corrects it, or rejects it.

For a follow-up action, the control gets stronger. The agent might propose tasks and draft notes, but the adviser should approve what enters the client record. It can prepare an email but not send it. It can identify a need for a risk profile review but cannot update the profile.

That distinction protects the client and keeps the accountable person in control.

You can see how this operational model fits into the broader Omni ops approach. The goal isn’t an AI assistant sitting off to the side. It is a defined business process with access rules, approval gates, and a record of decisions.

Advice documents need stronger gates

The highest-value use cases are often the ones that deserve the tightest control.

SOAs, ROAs, file notes, and related advice documentation take serious paraplanner time. A single document can absorb $3,000 to $8,000 of paraplanner cost once you account for information gathering, drafting, review cycles, corrections, and record keeping. Cycle times can stretch into weeks when the underlying meeting notes, product data, and client facts are incomplete.

The Advice Document Agent can help by drafting SOAs, ROAs, and file notes from a meeting transcript, approved fact find data, and the firm’s compliance template.

The important phrase there is approved fact find data.

An agent should not decide that a transcript has superseded the current client profile. It should not pull information from a stale document and present it as current. It should not generate a final advice document and route it to a client.

A sound runtime design separates preparation from authority.

The agent can:

• Collect approved source records and identify gaps.
• Build a first document draft using the firm template.
• Link each key factual statement to its source record.
• Flag contradictory data, missing disclosures, or sections requiring professional input.
• Route the draft to the paraplanner and authorised adviser.
• Preserve the review history and version changes.

The human approval gate should require the reviewer to see what has changed and what the agent could not verify. A simple “approve” button with no context is not strong governance.

For example, if the transcript says the client may retire earlier than expected, the agent can highlight that statement. It should not write a retirement assumption into the advice basis without a human confirming the fact find and implications.

That isn’t a technical nicety. It is how you stop automation from turning conversational fragments into formal client records.

The same design applies to the tools your staff access through Omni advisory. Good governance gives people faster preparation and better visibility. It does not transfer responsibility for advice to a system.

Onboarding is where loose permissions create problems

Client onboarding is another workflow with a tempting automation opportunity.

For many firms, onboarding takes 30 to 60 days. Some delay is outside the firm’s control. Clients need time to provide identity documents, statements, trust details, and responses to fact-find questions. Still, plenty of delay comes from unclear requests, repeated chasing, documents arriving in the wrong inbox, and incomplete handoffs between client services, advisers, and compliance.

The Client Onboarding Agent runs a guided fact find, requests KYC documents, tracks completion, and prepares a clean onboarding pack for the adviser.

Done well, that can preserve client momentum. Done poorly, it can create a serious privacy and process problem.

A controlled onboarding agent should be allowed to send approved request templates, receive documents through an approved channel, validate that a required item has been supplied, and prompt a human when something is unclear.

It should not:

• Decide a KYC document is authentic.
• Confirm that identification requirements have been met without human review.
• Alter a client’s risk profile based on partial responses.
• Make a representation about the firm’s acceptance of a client.
• Send sensitive information to a recipient that has not been verified.

The agent’s permission set should change by stage. At the beginning, it may have access only to a prospective-client workspace. Once the client is accepted and properly created in the core system, the relevant approved records can become available. This is much safer than creating an all-access automation account because it is convenient.

The audit record should show each request, each uploaded document, each reminder, each human review, and the exact point when a staff member accepted or rejected the pack. If a document was removed, the record should show who did it and why.

That is runtime governance. It isn’t a document stored in a compliance folder. It is the set of controls that determine what the agent can do at each moment.

Build the control model before building the agent

A practical control model has five layers.

First, define the workflow boundary. Pick one job with a clear start, end, owner, and business outcome. Meeting preparation is often a better first use case than “automate the whole advice process.”

Second, map data access. List every system and data category the agent needs. Then remove access it doesn’t need. Be precise about client household data, portfolio platforms, CRM notes, document stores, communications, and approved templates.

Third, set approval thresholds. Not every action carries the same risk. Creating a draft meeting brief may need adviser review. Creating a client-facing document needs formal approval. Updating a compliance-critical record may require a different role entirely.

Fourth, create exception paths. The agent needs a defined way to stop and escalate. Missing data, conflicting records, unusual client circumstances, unclear document images, and requests outside the approved workflow should trigger a human queue.

Fifth, retain evidence. Your audit trail should capture the agent version, workflow trigger, sources consulted, actions proposed, human approvals, exceptions, and final outcomes. If you can’t inspect the trail, you can’t manage the process with confidence.

There is no universal permission matrix for every advisory firm. A four-person practice and a 60-person group have different roles, systems, and licensee obligations. The discipline is the same.

Start with the smallest sensible level of access. Make consequential actions approval-based. Record what happened.

If you’re deciding where your existing processes are safe to automate and where they aren’t, see Omni for financial advisory firms. It focuses the discussion on the operational constraints in your firm, not generic AI features.

What an Omni Audit produces

An Omni Audit is a 60-minute working session. It is not a sales deck and it is not an AI maturity questionnaire.

We work through the manual workflow, identify the systems and people involved, and locate the points where runtime controls are required. For advisory firms, that usually means looking closely at meeting preparation, advice production, onboarding, or a related client-service process.

You leave with three outputs:

1. A workflow map showing where time, rework, and approval delays are sitting.
2. A shortlist of AI agent opportunities, ranked by operational value and control complexity.
3. A practical first-step plan covering data access, human approvals, exception handling, and audit evidence.

The outcome may be that a Meeting Prep Agent is ready to build now, while the Advice Document Agent needs better source-of-truth discipline first. That is useful. A firm shouldn’t automate a messy process into a faster compliance problem.

It may also show that the first win is not document generation at all. One trades-business owner in our network described the value of structured intake as finally knowing where each job was stuck. Advisory onboarding has the same dynamic. Visibility and controlled follow-up can produce value before you automate complex judgement.

For further context on how teams are applying AI to real operating work, our insights library and practical guides are useful starting points. Then bring your own workflow and systems into the conversation.

Make agents accountable before making them busy

There is a rush to give AI more work. Financial advisory firms should take a more disciplined route.

Don’t ask first, “What can this agent do?” Ask, “What is it permitted to do, who approves it, and can we prove what happened?”

That approach still delivers speed. Advisers get better prepared for meetings. Paraplanners spend less time assembling repeatable first drafts. Client services teams stop chasing the same missing document through three channels. The difference is that the firm keeps control of client data, professional judgement, and compliance evidence.

The $70,000 to $200,000 annual leakage range is not recovered by buying a chatbot licence. It is reduced by redesigning high-volume workflows, removing low-value manual handling, and placing proper controls around the automation that remains.

If you want to identify the first controlled agent worth deploying, Book a 60-min Omni Audit.

You can also review the AI audit for financial advisory firms before the session. Bring one workflow that frustrates your team every week. We’ll map the work, the permissions, the human decisions, and the audit trail it needs.