Blockchain and AI
Establishing whether your case is one of the few where a distributed ledger genuinely improves an AI system, and building it properly if so — with the expectation that the honest answer is often a database.
Most propositions combining blockchain and AI are two technologies looking for a shared problem. There is a real and narrow case where the combination is genuinely better, and being clear about where that line falls is more useful than a page of possibilities.
Blockchain and AI integration applies distributed ledger technology to AI systems, principally to establish tamper-evident provenance of data, models and outputs across parties who do not share a trusted central authority.
The question that decides it
A distributed ledger earns its cost when several independent parties need a shared record and none of them can be the authority. That is a narrow condition, and it is the test we apply:
| Situation | Ledger warranted? | Why |
|---|---|---|
| One organisation records its own data lineage | No | A database with audit logging is simpler and faster |
| A regulator needs to inspect your records | No | They accept your systems; a ledger adds nothing |
| Competing parties share a supply chain record | Possibly | No party can hold the authoritative copy |
| Content provenance across a public ecosystem | Possibly | Verification by parties with no relationship to you |
| Model outputs attested between untrusting firms | Possibly | Neither side can be trusted to keep the log |
| Paying for AI compute or data across parties | Possibly | Settlement without an intermediary |
| Storing training data or models on-chain | No | Wrong tool; ledgers are unsuitable for bulk data |
We will usually tell you not to
Most enquiries here resolve to a database with proper audit logging, cryptographic hashing and signed records — which delivers the tamper-evidence people actually want at a fraction of the operational cost and complexity. That recommendation is free and it is the most common outcome of the assessment.
Where it does genuinely apply
Content provenance and authenticity
As synthetic media becomes ubiquitous, verifying that a piece of content came from where it claims — and has not been altered — is a real problem with no central authority. Signed provenance records anchored to a ledger allow verification by parties who have no relationship with the publisher. See creative and media AI.
Multi-party data and model lineage
Where several organisations contribute data to a shared model and each needs assurance about what was used, when and under what terms, a shared record none of them controls is genuinely useful. This is a real pattern in consortia and federated arrangements.
Attestation of AI decisions between parties
Where an AI decision affects a counterparty who may later dispute it — an insurance assessment, a supply chain rejection, a marketplace ranking — a tamper-evident record of which model version produced what, when, is worth more than either party's own logs.
Supply chain claims that AI verifies
Combining computer vision or document analysis with an immutable record: what was inspected, by which model, with what result, at which point in the chain. The AI produces the claim and the ledger makes it verifiable downstream by parties who did not witness it.
What we do not do
We do not design token economics, issue or advise on digital assets, or build anything whose primary purpose is speculative. We are not financial advisers and this is not investment advice. Engagements here are about verifiable records, not about creating a tradeable instrument.
Building it properly if it is warranted
- Establish the trust model first. Who the parties are, what each can and cannot be trusted with, and what happens when one leaves. This determines everything, including whether a ledger is needed at all.
- Keep data off-chain. Hashes and signed attestations on the ledger; the data itself in appropriate storage. Personal data on an immutable ledger conflicts directly with deletion rights.
- Choose permissioned over public for most enterprise cases — known participants, lower cost, predictable performance, and no exposure of transaction patterns to the world.
- Design the governance, not just the chain. Who may join, who may write, how disputes are resolved, how the arrangement is wound up. Consortium failures are governance failures far more often than technical ones.
- Address the privacy conflict explicitly. Immutability and the right to erasure pull against each other, and the resolution — off-chain storage with on-chain hashes — has to be designed rather than hoped for. See data privacy for AI.
- Cost it honestly, including the operational burden of running or participating in a network over years.
How the engagement runs
Whether a ledger is warranted is settled first, and the answer is frequently no.
Trust model assessment
Parties, trust relationships and the shared-record requirement examined; the ledger-versus-database recommendation made.
Architecture
Where warranted: permissioned design, on-chain versus off-chain split, governance model and privacy resolution.
Build
Attestation and provenance implemented, integrated with the AI systems producing the claims.
Multi-party testing
Tested with real participants, including a party leaving and a disputed record.
Handover
Governance documentation, operational runbook and cost model handed over.
What you receive
An honest answer on whether you need this, and a properly governed implementation if you do.
Trust model assessment
Whether a ledger is warranted, with the database alternative costed where it is not.
Architecture
Permissioned design with a justified on-chain and off-chain split.
Provenance and attestation implementation
Integrated with the AI systems producing the claims.
Governance model
Membership, write rights, dispute resolution and wind-up arrangements.
Privacy resolution
How immutability and erasure obligations are reconciled, designed rather than assumed.
Cost model
Including the multi-year operational burden of participating in a network.
Is this the right engagement?
Worth being direct. Blockchain and AI is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- Several independent organisations need a shared record none can control.
- Content provenance must be verifiable by parties with no relationship to you.
- AI decisions affect counterparties who may later dispute them.
- A consortium or federated data arrangement is being established.
- Supply chain claims produced by AI must be verifiable downstream.
Choose something else if
- One organisation records its own data — use a database with audit logging.
- The requirement is data lineage internally. See data strategy and architecture.
- You want token economics, digital asset issuance or anything speculative.
- Personal data would need to be immutable, which conflicts with erasure rights.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
Do we need blockchain for our AI project?
Usually not, and that is the most common outcome of this assessment. A database with proper audit logging, cryptographic hashing and signed records delivers the tamper-evidence most organisations actually want, at far lower operational cost. A ledger earns its place only when several independent parties need a shared record and none can be the authority.
What is the genuine use case?
Provenance and attestation across parties who do not trust each other: content authenticity verifiable by strangers, multi-party data and model lineage in consortia, tamper-evident records of AI decisions that a counterparty might dispute, and supply chain claims that need verifying downstream by people who did not witness them.
Can we store our training data on-chain?
No — ledgers are unsuitable for bulk data and it would be extremely expensive. The correct pattern is hashes and signed attestations on-chain with the data itself in appropriate storage, which gives you tamper-evidence without the cost or the immutability problems.
What about GDPR and immutability?
They pull against each other directly, and the resolution has to be designed rather than hoped for. Personal data does not go on an immutable ledger; hashes and attestations do, with the underlying data held off-chain where it can be corrected or erased. Any design that puts personal data on-chain has a problem it cannot solve later.
Do you work with tokens or digital assets?
No. We do not design token economics, issue or advise on digital assets, or build anything whose primary purpose is speculative, and nothing here is investment advice. Engagements are about verifiable records between organisations, not about creating a tradeable instrument.
Often paired with this
Most clients combine two or three engagements from the Emerging and Frontier AI pillar. These are the ones that most often run immediately before or after.
Quantum-Adjacent Machine Learning
A straight assessment — no advantage on ordinary business data today, and the quantum work that does have a deadline.
Read more →AIoT: AI and IoT Integration
Analytics at the edge on sensor data, with the labelling problem solved and alerts that lead to action.
Read more →Digital Twins and Simulation
Twins scoped to a specific decision, validated against reality, at the fidelity the question actually requires.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.