The dangerous draft isn't the bad one, it's the one that's 90% right, because you'll read past the 10%. That's the design problem at the centre of suitability report automation. A machine can safely draft the sections built from facts you already hold, it can assist on the analysis, and it must never originate the personal recommendation or the reasoning behind it. Automate by section rather than by document, and build the review so a wrong sentence is easy to spot instead of easy to miss.
Key takeaways
- Automate by section, not by document. The sections carry different risk and deserve different treatment.
- Generated, assisted, never is the useful split: facts you hold, analysis you check, judgement you own.
- A draft that's mostly right is the hard case, because plausible text stops being read.
- Demand reproducibility: the same case, run twice, should give you the same report.
- When the system doesn't know, it should say so. An invented value is worse than a blank.
What can a machine safely draft in a suitability report?
Anything the firm already knows and can point at.
A suitability report is not 1 kind of writing. It's a stack of different jobs bolted together: restating facts, disclosing charges, explaining a product, comparing options, and setting out a personal recommendation with the reasoning that supports it. Those jobs carry completely different risk. Treating the whole document as 1 automation target is how firms end up either automating nothing or automating something they shouldn't.
Split it into 3 tiers.
Tier 1: safe to generate
These sections are transcriptions of data you already hold, so a machine writing them adds speed without adding invention.
- Client circumstances. Income, assets, liabilities, dependants, employment. Straight from the fact find.
- Objectives, as recorded. What the client said they want, in the words agreed with them.
- Charges and costs. Product charges, adviser charges, platform costs, pulled from source rather than typed.
- Product features and risks. Factual descriptions and standard risk warnings, drawn from provider documentation.
- Administrative sections. Scope of advice, what's excluded, next steps, cancellation rights.
The rule for tier 1 is that every sentence must be traceable to a field or a source document. If a sentence can't be traced, it isn't tier 1, whatever it looks like.
Tier 2: assisted, and always checked
These need judgement, and a machine can do the first pass and show its working.
- Comparison of options. A system can assemble the candidates, the costs and the features side by side. Which ones were genuinely viable is your call.
- Why alternatives were rejected. A draft based on the recorded reasons is a useful starting point. The reasons themselves come from you, and a system that infers them is guessing.
- Cashflow narrative. Turning a projection into readable prose is a good use of automation. The assumptions inside it are an advice decision, and they must be stated, not buried.
- Plain English explanation. Rewriting a technical paragraph so a client can follow it is a real strength. Check that simplifying didn't change the meaning, because that's the failure mode.
Tier 2 output should arrive with its sources attached. If you can't see what the draft was built from, you're not reviewing it, you're proofreading it.
Tier 3: never generated
Some things must originate with the adviser, and no efficiency argument changes that.
- The personal recommendation. What you're advising this client to do.
- The reasoning that ties the recommendation to this client. Not a generic paragraph about why the product suits people like them. Why it suits them.
- Anything about the client's understanding. Whether a client grasped a risk isn't inferable from a file. You were there.
- Vulnerability and capacity judgements. A system can flag indicators. It can't conclude.
A tool that writes these for you isn't saving you time, it's producing something you'll have to unpick and rewrite to make honest, and you'll be signing your name under whatever you missed.
Why a mostly right draft is the hard case
If a draft is obviously wrong, you fix it. The risk sits with the draft that reads well.
Fluent, confident text lowers your guard. Read 6 pages of correct prose and your attention drops on page 7, which is where the transposed number sits. This is a known human failure around automated systems, it gets worse the more reliable the system usually is, and it gets worse again at 9pm on a Thursday when the report has to go out.
So the design question isn't "how good is the draft". It's "how does a wrong sentence make itself visible". Systems that help do it by showing provenance, flagging what they couldn't source, and keeping the structure identical every time so your eye knows where to land.
How to review a machine drafted report
A method that works, and takes less time than reading start to finish:
- Check the numbers against source first, before you read a word of prose. Every figure in the report against the field or document it came from. Numbers are where the damage lives.
- Read the recommendation and the reasoning cold, as if you'd never seen the case. If it could apply to another client with a different objective, it's too generic to be a personal recommendation.
- Read the joins. Automated drafts fail at the seams between sections, where 2 correct paragraphs contradict each other.
- Look for what's missing. A system will rarely tell you it left something out. Check the awkward part of the case is in there.
- Ask what it couldn't source. A good tool gives you that list. If it doesn't have one, assume it filled the gaps.
Reproducibility is a requirement, not a nice to have
Run the same case through the system twice. You should get the same report.
If you don't, you can't review the system, only individual outputs, and you have no basis for telling your compliance oversight how the firm's reports are produced. Variation also destroys the consistency that makes file review fast: if every report is structurally different, you read every one cold.
Ask a vendor this directly, and ask what changes when they update their models. A system whose output shifts silently under you is a system you'll have to re-validate without knowing you should.
What automation must do when it doesn't know
Return a clear result, an honest "not available", or an error with a reason. Never a plausible fallback.
This matters more in advice than almost anywhere else, because a wrong number in a suitability report doesn't stay in the system. It goes to a client with your name at the bottom. A blank gets chased. A confident wrong figure gets used.
If you take 1 question into a demo, make it this one: show me what happens when the data isn't there.
Frequently asked questions
Can a suitability report be fully automated?
No, and a firm shouldn't want it to be. The factual and administrative sections can be generated from data you already hold, the analysis can be drafted and checked, but the personal recommendation and the reasoning that connects it to this client have to come from the adviser. Full automation means signing your name to reasoning you didn't do.
Is an AI generated suitability report compliant?
The document is compliant or not on its own terms, and how it was produced doesn't change the standard it has to meet. What changes is your evidence: you need to show who checked it, what changed between draft and final, and that the recommendation is genuinely personal. A report nobody meaningfully reviewed is a problem whether a person or a system drafted it.
How long should reviewing an automated draft take?
Less time than writing from scratch, or the tool has failed. If reviewing takes as long as drafting did, you've moved the work rather than removing it. Time both on a real case before you commit, and count the checking honestly, including the numbers verification.
What's the biggest risk with automated report writing?
Automation bias. Fluent text gets read less carefully than clumsy text, so errors inside a good looking draft survive review more often than errors in a bad one. The defence is structural: check figures against source before reading the prose, and use tools that show you what they couldn't verify.
Should the same system draft and check the report?
A system can run consistency checks on its own output and that's useful, but it isn't a second opinion, and it shouldn't be recorded as one. The sign-off has to be a person with the competence to disagree with the draft, and the file should show who that was.