Who is accountable for errors in AI-assisted wealth advice and execution?

Accountability should remain with the business role that approved the recommendation or execution, even when AI helped prepare the workflow. Banks should make that accountability explicit in approval records, role design, and audit trails so the human decision owner is always identifiable.

Why This Matters for Security Teams

AI-assisted wealth advice and execution changes the speed of decision-making, but it does not change the need for accountable ownership. If a model drafts a recommendation, ranks portfolios, or prepares an order for execution, the business still needs a named decision owner who can explain why the action was approved. That is where governance often fails: the workflow looks automated, but the responsibility is still operational, legal, and supervisory.

Current guidance from the NIST Cybersecurity Framework 2.0 supports clear accountability, but in wealth operations the harder problem is traceability across people, models, and systems. If approval records only show “AI assisted,” auditors cannot determine who accepted the recommendation, who overrode controls, or who had authority to execute. That becomes especially serious when advice flows into trading, rebalancing, tax-loss harvesting, or client suitability decisions.

NHIMG research on the DeepSeek breach shows how quickly AI-related exposures can expand once systems are misconfigured or overexposed. In practice, many security teams discover accountability gaps only after a bad recommendation has already been executed, rather than through intentional control testing.

How It Works in Practice

The cleanest model is to separate model assistance from business accountability. The AI can prepare a recommendation, generate a rationale, or draft an execution package, but a licensed or authorised human role must approve, reject, or modify the action. That approval should be captured with timestamps, role identity, the specific inputs reviewed, and the version of the model or workflow used. In other words, the record must show who owned the decision, not just which tool produced it.

This is consistent with the operational logic in the NIST Cybersecurity Framework 2.0, where governance and traceability are foundational rather than optional. For wealth firms, that means:

• Assigning one accountable role for advice approval and one for execution approval where those functions are separate.
• Keeping model output, human edits, and final decision evidence in immutable audit logs.
• Recording whether the AI was advisory, preparatory, or determinative in the workflow.
• Requiring exception handling when the recommendation crosses suitability, concentration, or policy thresholds.
• Reviewing approval rights periodically so delegated AI-assisted processes do not drift into unsupervised automation.

For NHI-heavy controls, the same discipline applies to machine actions that support human decisions. NHIMG’s DeepSeek breach coverage is a reminder that once AI systems interact with sensitive data and workflows, weak boundaries and poor logging can turn a normal process into a governance incident. These controls tend to break down when firms allow straight-through processing without a clearly recorded human decision owner because the approval chain becomes too thin to reconstruct after the fact.

Common Variations and Edge Cases

Tighter approval controls often increase operational friction, requiring organisations to balance client speed against defensibility. That tradeoff matters in wealth management, where some use cases are low risk and others are highly sensitive. Best practice is evolving, but there is no universal standard for this yet.

For example, an AI tool that summarises market data may be fully supervised by a portfolio manager, while an execution engine that places orders needs stronger segregation of duties, stricter thresholds, and more detailed review evidence. The same principle applies when the system is only “suggesting” trades: if the human reviewer rubber-stamps the output without meaningful review, accountability may exist on paper but not in practice.

Edge cases also arise in shared-service environments. If compliance, advisory, and trading teams all touch the workflow, the firm should designate a single accountable role for each decision point and make the handoff explicit. Where the process is multi-tenant or outsourced, contract language should preserve internal accountability rather than shifting it to the vendor. In practice, firms that rely on informal approval chains often find that ownership becomes unclear only after a loss, a suitability challenge, or a post-trade investigation.

Related resources from NHI Mgmt Group

• How should MSSPs govern AI-assisted incident triage across multiple tenants?
• How should organisations govern AI-assisted knowledge discovery in service teams?
• Who is accountable when an AI SOC analyst misranks an incident?
• How should teams govern AI-assisted service workflows without losing accountability?