Consistent AI investment proposals start with the data layer

An advisor preparing an investment proposal today typically pulls from three places: the CRM for the client's risk profile and objectives, the portfolio or custody system for current holdings and performance, and a research or product database for what to recommend.

Reconciling those manually, then drafting a narrative around them, is where most of the time in proposal preparation actually goes.

Adding a language model to that workflow without changing anything else does not fix the inconsistency. It reproduces it.

A model asked to draft a proposal by querying three separate systems will describe the same client's risk profile differently depending on which system's field it read that day, and two proposals for the same client, generated a week apart, can disagree on basic facts.

That is not a model quality problem. It is a data problem the model cannot solve on its own.

Why "just add AI" does not fix the inconsistency

Generative models are fluent regardless of whether the facts underneath are correct or current. A proposal drafted from a stale CRM field reads exactly as confidently as one drafted from an accurate one.

This is the gap between output that sounds right and output that is right — precisely where manual review used to catch errors, at the cost of the advisor's time.

Just 14% of organizations report fully integrated data readiness for AI initiatives (McKinsey, 2026).

Proposal generation is a concentrated version of that broader problem: a single client record touches multiple systems of record, and the model only produces a consistent proposal if those systems agree before it starts writing.

Source: McKinsey, "State of AI Trust in 2026," 2026

The fix: reconcile the data once, before generation

The architecture that makes this work reconciles a client's risk profile, current holdings, and approved product data into one structured record before any proposal generation happens.

The model then drafts from that single record, not from three systems queried independently at generation time. Consistency becomes a property of the data model feeding the automation, not a hope about how the language model happens to behave on a given day.

This single-record approach also gives compliance a fixed point to review. Instead of reconstructing which system a given fact came from after the fact, the reconciled record is the one place that answer lives.

Guided generation: the model drafts inside fixed rules

A correct data layer is necessary but not sufficient on its own. The proposal also needs to follow the firm's own template, house view, and required disclosures every time, regardless of which advisor requests it.

That means constraining the model with the firm's own investment guidelines and document structure, rather than leaving format and content to its discretion. The model fills in a fixed structure from a fixed record; it does not improvise either one.

Investment proposals in the EU also carry a specific compliance stake: firms providing investment advice must give clients a statement of suitability, explaining how the recommendation matches their profile, before the transaction is concluded (MiFID II Article 25(6), Directive 2014/65/EU; ESMA).

A proposal drafted from a reconciled, structured record can carry that explanation consistently. One built from whatever a model retrieved on a given day cannot make the same guarantee.

Why this runs on-premise

Client risk profiles and portfolio holdings are among the most sensitive data a wealth manager holds. Running inference on-premise, inside the wealth manager's own infrastructure, means that data never leaves the firm's environment to reach an external model during proposal generation.

The reconciled client record, the model's reasoning over it, and the resulting draft all stay inside infrastructure the firm already controls and audits. Consistency and data control are solved by the same architecture decision, not two separate ones.

What actually changes for advisors

The advisor no longer opens three systems to assemble a first draft. Every proposal starts from the same governed client record, regardless of who requests it or when.

Review shifts from checking whether the underlying facts are even correct, which used to be the slow part, to checking whether the recommendation itself fits the client. The advisor still makes that judgment call on every proposal; the automation exists to remove the manual reconciliation before it.

The bottom line

A language model can draft a fluent investment proposal from almost any input, correct or not. What determines whether that proposal is consistent across advisors, across clients, and across time is whether the data feeding it was reconciled into one structured source of truth first.

Get the data layer right, on-premise, and the model becomes a genuinely reliable drafting tool rather than a fluent way to reproduce whatever inconsistency already existed upstream.