AI and MiFID Compliance: Advice, Suitability and Records

MiFID obligations were written for human processes, and AI in investment services runs into them at several points. The pattern is consistent: AI can prepare and evidence, while the regulated judgement stays with the firm. This guide covers where the lines sit, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

Where do AI systems meet MiFID obligations?

At several points, each with a different boundary between preparation and judgement.

Obligation	Where AI fits
Suitability	Prepare and evidence; firm judges
Appropriateness	Gather and structure; firm assesses
Best execution	Analyse and monitor; policy stays firm's
Record-keeping	Records must cover AI contributions
Algorithmic trading	Controls apply where order flow is affected
Client communications	Fair, clear and not misleading applies

Can AI make suitability assessments?

It can gather client information, structure it against product characteristics, surface gaps, and prepare an assessment. The firm remains responsible for the suitability judgement and the recommendation.

That boundary should be structural: the system prepares, an authorised person approves, and the record shows both. A design where the system's output can reach a client without qualified approval has moved a regulated judgement into software, which is a different arrangement than most firms intend.

What record-keeping applies?

Records of client communications and of the basis for recommendations, kept for defined periods.

Where AI drafts a communication or contributes to a recommendation, the record needs to show what the system produced and what the adviser decided. Systems that overwrite the draft with the final version lose exactly the evidence that demonstrates human judgement was applied.

Do algorithmic trading rules apply?

Where AI affects order generation, routing, or execution decisions, yes — including requirements around testing, risk controls, kill functionality, and monitoring.

Those rules are prescriptive and predate the current AI wave, and they are unforgiving about systems whose behaviour cannot be constrained or stopped. A component whose outputs feed order flow needs the same controls as any other algorithm, plus a defensible answer about how its behaviour was tested.

What evidence do you need?

Suitability records showing what the system prepared and what the adviser decided, communication records including AI-drafted content and the final version, algorithmic trading testing and control evidence, and model version records tied to periods of use.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes draft retention, approval capture, and version records into the build. Keeping both the system's output and the human's final version is the evidence that judgement was applied, and it costs almost nothing if designed in.

For anything touching order flow, kill functionality and hard limits are engineering requirements rather than operational procedures, and they need testing as such.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Letting AI-drafted client communications reach clients without approval capture. Overwriting drafts with final versions. Treating a component that influences order routing as outside algorithmic trading rules. And allowing model versions to change without records.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How does this interact with the EU AI Act?

They stack. Financial services obligations apply through existing supervision, and AI Act obligations apply where a system falls within its scope — including creditworthiness assessment, which is explicitly addressed.

One evidence base serves both: testing, documentation, oversight design, and records answer supervisory questions and Act obligations alike. See EU AI Act high-risk obligations.

What should you do first?

Check whether any AI-drafted client communication can reach a client without a recorded human approval. That path is the most common gap and the easiest to close.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: both the system's draft and the approved final version retained so human judgement is evidenced, hard limits and kill functionality built where order flow is touched, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read AI and Basel model risk.