When not to use AI for trading
Most writing on AI and trading is about how to use it. The more useful boundary is where it actively costs you something, because those cases are specific and several of them are the ones people reach for first.
When you are losing
This is the big one. After a run of losses, “let me get a second opinion from the model” is the most natural move available and close to the worst.
Two reasons, and they compound.
It will agree with you. Not because it is sycophantic, but because you supply the framing. “Is this setup still valid” contains a thesis, and a model producing the most plausible continuation of your framing is not an independent check. You have added a step that feels like verification and provides none.
It removes friction from a decision that needed friction. The pause before a revenge trade is doing work. Filling it with a plausible-sounding analysis converts hesitation into justification.
What you need after several losses is a cooldown enforced in code, which does not have an opinion and cannot be consulted. Adding a model here is adding a participant to a conversation you should not be having.
When you want permission
Related and worth separating. If you have decided and are looking for agreement, a model will provide it — reliably, articulately, and with reasoning that sounds like your own but better expressed.
The tell is in the question. “Should I take this trade?” is an open question. “Here is why this trade makes sense — thoughts?” is a request for ratification. The second reliably gets it.
When the answer is arithmetic
If the question has a deterministic answer, compute it. Position size, liquidation distance, fee impact, recovery required — these are calculators, and a calculator is exact, reproducible and free.
A model will usually get them right, which is the problem: usually is worse than always, because it trains you to stop checking. Use the model to decide which calculation matters; use code to do it.
When you cannot verify the output
If you would not notice a wrong answer, do not ask the question.
This is the practical form of the hallucination problem: the risk is not being wrong, it is being wrong undetectably. If a claim cannot be checked against something, treat it as unusable regardless of how reasonable it sounds.
When it needs to be deterministic
Rules that must execute identically every time belong in code. A limit in a prompt is a strong input to a probabilistic process — it holds most of the time, which is precisely why you stop checking it, and it fails in the unusual situations that motivated it.
This applies to risk limits, entry criteria you can actually specify, and anything that must not vary with phrasing. See MCP server vs trading bot for the fuller version.
When the model is reading untrusted text and holding order tools
Do not combine these. Anything the model reads enters the same context as your instructions, and the architecture does not distinguish them by origin — prompt injection is a structural property rather than a defect.
Research in one session, trade in another. This is a workflow constraint and it is the only measure that removes the category rather than reducing its rate.
When latency matters
A model round trip takes seconds. If your edge depends on acting faster than that, a model is not in the loop and should not be. That is a narrow case and worth naming, because “AI trading” implies speed it does not have.
When you have not defined what you are asking
A vague question produces a fluent answer, and the fluency disguises that the question was never specified. “What do you think of BTC here” gets you a paragraph; it does not get you a decision, and it can feel like it did.
If you cannot state what would change your mind, the model cannot help — and will nonetheless produce something that reads as though it did.
Where it is genuinely worth it
For contrast, the cases that hold up:
- Reading state — exposure, costs, what you did not check.
- Explaining mechanics — why a position behaves as it does.
- Structuring an idea into a plan with an entry, a stop and a size.
- Reviewing your own record afterwards, especially the trades you rejected.
All of it works with read-only access. The pattern is that the model is most useful where the answer is checkable and least useful where it is not — see a workflow for trading with an AI copilot.
The rule underneath all of these
Do not put a model where you needed a constraint.
Every case above is a version of that. Losing streak: you needed a cooldown. Deterministic rules: you needed code. Arithmetic: you needed a calculator. Seeking permission: you needed the decision to already be made.
A model is a good reader and a fluent writer. It is not a limit, and using it as one produces something that feels like a safeguard while providing none.
FAQ
Should I ask AI about a trade I am losing on?
Generally no, and it is the most tempting case. You supply the framing, so the model’s answer tends to confirm it, and the pause you filled with analysis was itself doing useful work. What helps after consecutive losses is a cooldown enforced in code, which cannot be consulted or persuaded.
Can AI help me stick to my trading rules?
Not as the enforcement mechanism. A rule stated to a model is an input it weighs, not a constraint it obeys, and it will be followed most of the time — which is the failure mode, because you stop checking. Rules that must hold belong in code that rejects the order.
Is AI useful for fast trading?
Not if the edge depends on speed. A model round trip takes seconds, which rules it out of anything latency-sensitive. Its value is in reading, explaining and structuring, none of which are time-critical.
When is AI most valuable in trading?
Where the answer is checkable: summarising exposure, explaining why a position is behaving as it is, catching costs and margin details you did not look at, and reviewing your own decision log. All of it works with read-only access, and none of it requires the model to know what happens next.