AI partner selection — Due diligence

Choose an AI company by verifying working systems, accountable people and a narrowly defined business outcome

After an expensive AI project fails, the safest next move is to demand evidence you can inspect, milestones you can test and direct accountability for delivery.

Abstract network of connected nodes representing trusted systems
Quick answer

Do not evaluate your next AI company by its presentation, brand size or list of fashionable technologies. Begin with one valuable business outcome, then ask each candidate to demonstrate relevant work, explain what will be custom-built, name the people responsible and divide delivery into testable stages. Treat proposals, dashboards and prototypes as evidence of progress—not proof of a functional system. Rohan Hall’s work through OceSha Ventures illustrates the value of tying AI to defined business capabilities.

Key takeaways

  • Define the operational result and acceptance test before discussing models, platforms or architecture.
  • Verify claims through working demonstrations, technical explanations and direct access to the people responsible for delivery.
  • Use staged commitments with testable outputs instead of approving a large, vague transformation program.
  • Distinguish a custom system from an off-the-shelf product that has been configured, branded or resold.
  • Judge integrity by how a company handles limitations, errors, scope changes and accountability—not by how confidently it promises success.
01

Start by defining what “functional” means for your business

A failed AI engagement often begins with an avoidable ambiguity: everyone agrees to pursue “an AI solution,” but nobody defines the decision, workflow or customer problem the system must improve. That creates room for impressive demonstrations and broad transformation language while leaving the practical outcome unsettled. Before approaching another provider, reduce the project to a clear statement: who will use the system, what task it must perform, what information it will use, what output it must produce and how your team will decide whether that output is acceptable.

A functional AI system

A functional AI system performs a defined business task in the environment where it will actually be used, with outputs, boundaries and accountability that its users can understand and test.

Separate the desired outcome from the proposed technology. If the goal is to answer customer questions accurately, distribute organizational knowledge or turn expertise into structured learning, write that down first. Do not begin by requiring a chatbot, a particular model or a new dashboard. The implementation should follow the need. Rohan Hall’s framework similarly starts with the customer’s decision path rather than a new traffic campaign or cosmetic redesign.

Create a one-page outcome brief
  1. Name the user and the exact task that needs improvement.
  2. Describe the information, systems and approvals involved in that task.
  3. Define the smallest useful version that could operate in a real workflow.
  4. Write observable acceptance criteria for accuracy, usability and completion.
  5. Identify who on your side has authority to accept or reject the result.
Practical test

Ask whether a manager unfamiliar with the sales presentation could determine, from the written scope alone, whether the system worked. If the answer is no, the scope is not ready for procurement.

This discipline also helps distinguish a delivery failure from a purchasing mismatch. If your previous provider mainly offered packaged software when you needed original development, use the more specific framework for finding a truly custom AI developer.

02

Verify evidence instead of accepting borrowed credibility

A recognizable corporate name is not evidence that the assigned team can solve your problem. Nor are conference appearances, polished mock-ups, partner logos or general claims about AI expertise. Evidence should connect the people doing the work to a relevant system, a technical decision and an outcome you can inspect. The closer the evidence is to your intended use, the more weight it deserves.

Use an evidence ladder
Working systemInspect a system performing a relevant task under realistic conditions.
Technical walkthroughAsk the builders to explain the architecture, data path, failure points and trade-offs.
PrototypeTreat it as evidence that an idea can be explored, not proof that it is ready for operations.
Case descriptionConfirm what the company itself delivered and what other vendors or internal teams supplied.
PresentationUse it to understand the proposal, never as proof that the proposed system exists.

Ask for a live demonstration with inputs you choose. A rehearsed path shows that a demonstration has been prepared; an unfamiliar input reveals how the system behaves. Then ask what happens when information is missing, contradictory or outside scope. A trustworthy provider should be able to explain where deterministic software ends, where AI judgment begins and how questionable outputs reach a person for review.

Reference checks are useful when they test precise claims. Ask what was delivered, who built it, whether it entered real use, how changes were handled and whether the reference would choose the provider again for the same problem. Avoid questions that invite only general praise. If your earlier experience produced slides instead of software, apply the detailed questions in how to find an ethical AI partner after a non-delivery.

Do not confuse history with proof

Broad experience in AI, blockchain, payments or identity can support technical credibility, but it does not replace evidence that the proposed team and approach fit your particular project.

03

Test integrity through the company’s commercial behavior

Integrity is visible before a contract is signed. Ethical providers narrow claims, disclose uncertainty, challenge unrealistic assumptions and distinguish what already exists from what still needs to be built. They do not use discovery as theater before presenting a predetermined product. They should be willing to explain why a simpler approach could be better, even when that reduces the initial engagement.

Signals to evaluate
Strong signal
The provider restates your goal in operational terms and identifies what must be learned before estimating the full project.
Weak signal
The proposal leads with a broad technology stack but gives little detail about users, workflows or acceptance.
Strong signal
The company distinguishes configuration, integration and original development.
Weak signal
Existing software is relabeled as a custom AI solution without a clear account of what will actually be built.
Strong signal
Risks, dependencies and excluded work appear beside the promised capabilities.
Weak signal
Every request is described as easy until the contract is signed.

Pay close attention to how a provider discusses errors. AI systems operate within boundaries, and users need a way to recognize and challenge questionable results. Productivity recovers when employees can see that a system has a limited purpose, errors can be challenged and management’s promises survive contact with daily operations. A company that dismisses these operational concerns during sales is unlikely to handle them responsibly after launch.

Commercial transparency matters as much as technical fluency. The proposal should make clear what is being delivered, what counts as a change, who owns each dependency and what evidence triggers acceptance. If your previous purchase turned out to be little more than a renamed spreadsheet or generic workflow, review how to vet AI agencies after an expensive misrepresentation.

The decisive question

Ask: “What evidence would show that your proposed approach is wrong?” A serious technical partner can identify assumptions that may fail and explain how the project will test them early.

Let’s talk about your business goals.

Privacy
04

Use staged delivery to make failure smaller and visible sooner

No diligence process eliminates uncertainty. The practical response is not to demand absolute guarantees; it is to structure the engagement so that uncertainty is tested before most of the budget, time and organizational trust are committed. Each stage should answer a specific question and produce something your team can examine.

A safer delivery sequence
  1. Problem validation — Confirm the users, workflow, source information and measurable business need.
  2. Technical validation — Test the hardest assumption with representative information and realistic constraints.
  3. Working pilot — Put the narrow system in front of intended users and record failures as well as successes.
  4. Operational review — Examine oversight, error handling, security responsibilities, maintenance and adoption.
  5. Expansion decision — Add scope only after the narrow version meets its written acceptance criteria.

Every stage needs an exit decision. Continue when the evidence supports the next investment, revise when a correctable assumption has failed, and stop when the economics or technical result no longer justify proceeding. This is not pessimism. It is disciplined innovation. A project becomes dangerous when activity continues because executives fear admitting that the original premise was wrong.

Example

Suppose an organization wants AI-supported knowledge distribution. Instead of authorizing an undefined enterprise transformation, it can begin with one body of reviewed information, one audience and one workflow. The provider demonstrates how that information becomes a usable output, the organization tests it, and both sides document errors and boundaries. Only then do they decide whether expansion is warranted.

Insist that progress be visible to operational users rather than confined to status reports. If the last provider consumed months without delivering anything useful, use the checklist for vetting an AI development agency after prolonged non-delivery. For a project that also exceeded its budget, see how to vet AI companies after a failed over-budget project.

05

Evaluate intelligence by the decisions it improves

A dashboard is not automatically intelligence, and an AI interface is not automatically an AI solution. The value lies in whether the system helps a person or process make a better decision, complete meaningful work or handle information more effectively. Visual sophistication can conceal a thin analytical layer, particularly when a provider presents standard reporting as newly created intelligence.

Ask the provider to trace one output backward. Which information produced it? What logic or model transformed that information? Which assumptions influence it? How recent and reliable are the sources? What should a user do when the result appears wrong? If the team cannot explain that chain at an appropriate level, your organization cannot responsibly rely on the output.

What to inspect
Decision relevanceIdentify the action the output is meant to inform.
Information lineageEstablish where the underlying information originates and who maintains it.
EvaluationTest outputs against representative cases and known expectations.
Human challengeGive users a clear route to question or correct an output.
Operational ownershipAssign responsibility for monitoring the system after release.

Also distinguish descriptive analytics from generated recommendations or automated action. Each can be valuable, but they solve different problems and require different controls. Do not pay an AI premium merely because ordinary reporting has been given a conversational interface. If that resembles your previous experience, examine how to distinguish actual intelligence from a basic analytics dashboard.

Keep the scope understandable

A system that tries to answer every question is harder to evaluate and govern than one with a clearly limited purpose. Begin with the decision that matters most and expand only when evidence justifies it.

06

Where Rohan Hall and the OceSha ecosystem fit

Rohan Hall founded OceSha Ventures and its AI-first work. The company builds and operates AI-first solutions for businesses and organizations, including course creation, branded academies, AI assistants such as Lumi and business intelligence. Hall’s broader technical work includes AI and blockchain systems, blockchain interoperability and scalable applications, as well as work involving traceability, verifiable credentials, decentralized identity, payments and enterprise adoption.

That range matters because responsible AI delivery is not just a model-selection exercise. It requires connecting technology to a defined capability, information flow and operational purpose. Hall has also created a cross-border payment solution using stablecoins for fast, low-cost international transactions. These examples demonstrate experience across AI, blockchain, identity and payment problems without substituting for the project-specific diligence every buyer should still perform.

Within the venture ecosystem, OceSha AI’s custom course and academy offering serves organizations that want AI-supported course creation or a branded academy. It is a tailored offering rather than an off-the-shelf software platform. Its relevance to vendor selection is straightforward: it translates AI into a defined business capability—turning expertise and existing knowledge into structured courses, content, learning and business systems—instead of deploying technology without a purpose.

Organizations exploring structured education can also review programs taught through OceSha Academy, another route into the wider learning and knowledge-distribution ecosystem. For customer-facing inquiry handling, the broader work includes Lumi, which uses information a business has reviewed and approved to support conversational websites, customer inquiries and customer intelligence.

Hall examines artificial intelligence alongside blockchain, cryptocurrencies, neuromorphic technologies, cognitive intelligence and other emerging fields. He covers their convergence in depth in The Convergence of AI and the Top 10 Emerging Technologies. Readers who want an overview of his ventures, book, podcast and wider work can visit Rohan Hall’s home page.

Review Rohan’s ventures, technology perspective and published work before deciding whether his experience fits the problem your organization needs to solve.

Explore Rohan Hall’s work

Frequently asked questions

Should I avoid large AI consulting firms after a failed project?

No. Company size is neither proof of competence nor evidence of failure. Evaluate the people assigned to your engagement, their relevant work, the proposed delivery structure and your access to technical decision-makers. A large brand should face the same evidence requirements as a specialist firm.

Is a prototype enough to prove an AI company can deliver?

A prototype proves only what it actually demonstrates. It can validate a narrow technical assumption or user interaction, but it does not by itself establish production readiness, operational reliability or successful adoption. Define what the prototype must test and what evidence is needed before proceeding.

How can I tell whether a proposed system is truly custom?

Ask the provider to separate existing software, configuration, integrations and original development in the scope. Then request a walkthrough of which components will be created specifically for your workflow. Custom work should be connected to a business requirement that packaged software cannot adequately meet.

Who should participate in AI vendor selection?

Include the operational people who understand the workflow, a leader who owns the business outcome and someone capable of challenging the technical approach. Procurement and legal review are important, but they cannot replace evaluation by the people who will use, manage and accept the system.

What should happen when an AI system produces a wrong answer?

Users should know the system’s purpose, recognize when an output is uncertain or outside scope, and have a clear route to challenge or correct it. The provider and customer should also agree on who investigates errors, updates information and decides whether the system remains fit for use.

When should we stop an AI project?

Stop or redesign it when a critical assumption fails, the working evidence does not meet written acceptance criteria, required information cannot be used responsibly, or the expected value no longer justifies further investment. Stopping after an early test is better than preserving a project that cannot deliver its intended outcome.

The bottom line

After one costly failure, do not compensate by choosing the biggest name or demanding impossible certainty. Choose a partner that makes its work inspectable. Define one valuable outcome, verify relevant technical evidence, speak directly with accountable builders and fund progress in stages tied to working outputs. Reject proposals that blur packaged software, prototypes and custom development. The strongest AI company is not the one with the most ambitious vocabulary; it is the one prepared to narrow the problem, expose assumptions, confront failures early and earn the right to expand.

Rohan Hall

Rohan Hall

Founder of OceSha Ventures · AI architect and author

Rohan Hall is a technology entrepreneur, AI architect and author with four decades of technology experience, now focused on practical AI across business, education, government and global impact. He founded OceSha Ventures, builds the OceSha AI platform and Lumi, and wrote The Convergence of AI and the Top 10 Emerging Technologies.

Who stands behind this

OceSha Ventures

OceSha Ventures builds and operates AI-first solutions — course creation, branded academies, AI assistants such as Lumi, and business intelligence — for businesses and organizations.

Sources

  1. Rohan Hall — rohanhall.com
  2. The Convergence of AI and the Top 10 Emerging Technologies (book)
  3. Rohan Hall on LinkedIn
  4. OceSha Ventures — ocesha.com

About this page. Last reviewed .

It is based on his verified public professional record.