I have sat through a lot of pitches in thirty years, and the ones pairing "AI" with "blockchain" are reliably the worst. Two genuinely useful technologies, welded together on a slide because both are fashionable, solving a problem nobody in the room can name. I'll say it plainly: this is mostly marketing.
But not always. So let me give you the test I actually use, and the handful of cases that pass it.
First, what each thing is for. AI finds patterns and makes decisions. It is terrible at proving why it decided something, or proving the decision and the data behind it weren't tampered with after the fact. Blockchain does one thing well — it produces a tamper-evident record that several parties who don't trust each other can agree on without a referee in the middle. It is otherwise useless at doing anything interesting with that record.
So the only reason to bolt them together is this: you have an AI decision, and you need multiple distrustful parties to be able to verify the inputs and the audit trail rather than take your word for it. That's it. That's the entire legitimate overlap.
Three questions decide it:
- Do multiple parties who genuinely don't trust each other need to share this data?
- Does a tamper-evident history actually change what people do?
- Would a well-kept audit log in Postgres, with sane access controls, do the job instead?
Most projects answer no, no, yes. If that's you, you don't need a chain. You need a database and someone who takes write-access seriously. I have watched teams burn two quarters standing up a permissioned ledger to do what an append-only audit table and a backup policy would have done in a fortnight.
Where it does pass:
Provenance across a supply chain. A food producer running AI on shipment data, with each reading written to a ledger the farmer, processor, shipper and retailer all read from. When a batch goes bad, there is no argument about who logged what. The distrust is real, the parties are real, the record changes the dispute. That clears all three questions.
Cross-institution research. Hospitals training a shared model without moving patient data, with a ledger recording who contributed which update and when. Useful for the regulator and for credit. Again — parties who can't simply trust each other's spreadsheets.
Model provenance. As generative output floods everything, a few teams sign their model outputs so a downstream system can ask "did a model produce this, and which one?" That's a real question with a real answer. Whether you need a public chain or just a signing key and a transparency log is a separate fight, and usually the key wins.
One technical caveat worth stating bluntly. If anyone is still proposing proof-of-work infrastructure — Bitcoin-class — for a supply-chain app, walk out. The energy economics are indefensible and there is no application reason for it. Proof-of-stake or a permissioned chain, or nothing.
The recurring mistake isn't that blockchain is bad technology. It's that people reach for it before they've written down the trust problem in one sentence. "Our auditors need to verify the deployed model is the one we trained, and they don't take our word for it" — that sentence has a real answer, and it might involve a ledger. "We're exploring synergies between AI and blockchain" is not a sentence. It's a funding round.
If you have the first kind of sentence, it's worth twenty minutes. If you have the second kind, save your money.
