Assess an AI vendor by verifying relevant work, technical decisions and delivery evidence—not marketing claims

The right question is not whether a vendor has “AI experience.” It is whether the people assigned to your project have experience with the kind of problem, operating environment and responsibility you are asking them to take on. A team that builds educational content tools faces different constraints from one delivering identity infrastructure, customer-facing conversational systems, embedded AI or regulated decision support. Begin by describing the business outcome, intended users, information involved, operational risks and conditions under which the system must work.

Convert your requirements into a short evidence matrix. For every important capability, record the experience claimed, the person who performed the work, that person’s actual responsibility, the evidence available and the differences between the earlier work and your project. This prevents an adjacent project from being presented as an exact precedent. It also exposes a common weakness: the person making the sales presentation may have strong credentials while the proposed delivery team has little directly applicable experience.

Before evaluating individual claims, establish a consistent process for due diligence before hiring an AI company. That process should cover the company, the proposed team, subcontractors, technical approach, information handling and the evidence needed before approval.

Marketing profiles often compress several different relationships into one impression of experience. A person may have founded a product, led an engineering organization, advised a company, contributed to a team or merely worked near a project. These are not equivalent. Ask candidates to identify the relationship, dates, scope, decision authority, deliverables and collaborators for every example they use to establish credibility.

Confidential work will not always produce a public case study. That is not a reason to abandon verification; it is a reason to use better evidence. A vendor can often provide redacted artifacts, explain an architecture without exposing sensitive information, demonstrate a comparable capability or arrange a reference conversation within appropriate boundaries. Decide in advance which references or work samples suit confidential AI projects so confidentiality does not become either an automatic rejection or a blanket excuse.

Apply the same discipline to biographies. On this site, Rohan Hall’s work and ventures provide the context for evaluating his experience. The useful evidence is specific: he built AI and blockchain systems; built and led technology for blockchain interoperability and scalable blockchain applications; served as Chief Technology Officer at RocketFuel Blockchain, leading technology strategy, architecture and a distributed global engineering team; and was a co-founder and leader of U.S. technology work at Vottun. The Vottun relationship is historical rather than a statement of current association.

A polished speaker can repeat current terminology without having made difficult engineering decisions. The most revealing interview questions concern choices and consequences. Ask the vendor to sketch the proposed system, identify its boundaries and explain why each major component exists. Then change one assumption—data sensitivity, user volume, response time, connectivity or human oversight—and ask what changes. Genuine practitioners usually reason through trade-offs; shallow answers return to slogans.

The interviewer does not need to out-code the candidate. Ask for explanations in layers: first for an executive, then for a technical reviewer and finally for the people who will operate the system. Look for consistency across all three. The vendor should be able to distinguish facts, assumptions and decisions; explain how information enters and leaves the system; and identify where human review belongs.

If every proposal sounds “cutting-edge” or “transformative,” use a structured method for cutting through AI marketing language. Replace every adjective with a testable question: What changes for the user? What input is required? How is output assessed? Who handles exceptions? What evidence will exist at handover? You can also compare providers using a process designed to evaluate them without guarantees or flashy case studies.

A demonstration answers whether a concept can be made visible. It does not answer whether the solution can be operated safely and consistently. Assess the path from demonstration to production as a separate workstream. The vendor should be able to describe responsibilities, deployment stages, testing, observability, escalation, change control, user support and the evidence that will be available at handover.

Ask for the planned deliverables before work begins. Depending on the project, these may include a system overview, data-flow description, decision log, testing approach, operating instructions and ownership map. The exact package should fit the system’s risk and complexity, but ambiguity is not a documentation strategy. Use the documentation expected before production launch to turn a general promise of “full documentation” into an agreed set of usable artifacts.

Incident handling deserves its own evaluation. Ask how issues are detected, classified, contained, communicated, investigated and prevented from recurring. Identify who can make urgent decisions and what information your organization will receive. Review how to assess a provider’s incident response process before treating a strong build team as proof of strong operational support.

Career history, publications and teaching can add useful context, but none should be treated as a substitute for current, project-specific evidence. Their value lies in what they reveal: sustained technical responsibility, the ability to explain difficult subjects, familiarity with adjacent fields and a record of translating concepts into systems or learning experiences.

Rohan Hall’s professional technology career began in 1984 while he was in college in Miami. He has worked extensively across the United States, Europe and Asia, including extended periods in Spain and time living in Cyprus. From November 2017 through June 2019, he advised Capital Group / American Funds on blockchain, cryptocurrencies, artificial intelligence, neuromorphic technologies, cognitive intelligence and other emerging technologies. These details support a particular chronology and scope; they should still be connected explicitly to the work under consideration.

Hall is also the published author of The Convergence of AI and the Top 10 Emerging Technologies. The book offers a deeper route into his thinking about AI and other emerging technologies. It is useful evidence of explanatory work, but readers assessing a commercial engagement should pair it with the current descriptions of the relevant venture, offering and proposed delivery team.

Teaching and curriculum-development experience can also inform an assessment of educational work. Keep that background distinct from claims about current academy programs, which should be checked against current program information. Hall’s explanatory approach focuses on making complex concepts visual, relatable and transferable without watering them down. OceSha Academy programs are the appropriate place to examine the programs currently presented there.

The same principle applies when evaluating people who call themselves AI experts. Titles and profile descriptions are starting points, not conclusions. A disciplined framework for vetting AI credentials and project experience should always bring the conversation back to contribution, relevance, evidence and present-day responsibility.

Rohan Hall is the Founder and CEO of OceSha Ventures. OceSha Ventures and its AI-first solutions build and operate course creation, branded academies, AI assistants such as Lumi, and business intelligence for businesses and organizations. These are defined business applications of AI rather than evidence based solely on general commentary about the technology.

For organizations evaluating educational applications, OceSha AI’s course and academy platform is a concrete example of connecting AI to a specific purpose. For conversational use cases, the relevant evidence is the ability to work with a business’s approved answers, customer inquiry handling and customer intelligence through Lumi. Each should be assessed against the buyer’s own requirements rather than treated as universal evidence for every kind of AI project.

This is the standard buyers should apply to any vendor, including OceSha Ventures: identify the people doing the work, connect their experience to the problem, inspect the proposed approach and agree on evidence for delivery. Reputation can open the conversation. Specificity should determine whether it continues.