Choose a replacement AI vendor by auditing what remains, defining a testable recovery scope and verifying delivery evidence

A bankrupt supplier creates two problems at once: an unfinished AI marketing platform and an uncertain record of what was actually built. Your first priority is therefore preservation, not replacement. Stop nonessential changes and create controlled copies of every asset you possess. That includes source code repositories, deployed applications, databases, training or reference data, model configurations, prompts, analytics, designs, architecture diagrams, requirements, testing records, invoices, contracts and relevant communications.

Identify which systems are still operating, who controls each environment and which services depend on the failed company. Record renewal dates, recurring costs and known outages. Preserve logs before retention periods expire. Change access where appropriate, but avoid deleting accounts or environments until a qualified person has confirmed that doing so will not destroy evidence or interrupt a functioning service. Obtain legal advice about ownership, insolvency proceedings, data rights and contractual remedies where necessary.

Nominate one internal decision-maker to coordinate the recovery, even if that person is not technical. Their job is to maintain the asset register, collect business decisions and prevent different departments from giving vendors contradictory instructions. If the deeper issue is that the initiative has been abandoned with no coherent handover, use the broader framework for making an abandoned AI initiative functional to decide what deserves preservation before rebuilding anything.

Do not rely on invoices, demonstrations or the former supplier’s reported completion percentage. Inspect working software and underlying assets. A feature that appeared in a demonstration may use placeholder data, manual intervention or an incomplete integration. Conversely, unattractive or poorly documented code may still contain valuable business logic, data structures or tested components. Recovery decisions should follow observable evidence rather than sunk cost or appearance.

The assessment may conclude that only part of the system should survive. That is not failure; it is a controlled reduction of risk. If the application is stalled because no one can explain its architecture or decisions, the related guide on finding an expert to rescue a half-finished AI system provides a useful way to distinguish technical recovery from ordinary feature development. For an integration that has lost its internal owner, consider the separate steps for finding an agency to take over an AI integration.

A trustworthy selection process depends on a brief that separates facts from assumptions. Describe the business outcome first: who will use the platform, which marketing decisions or customer interactions it must support, and what must be measurably true for the project to be accepted. Then provide the current asset inventory, known defects, legal or operational constraints, required integrations and the assessment findings. Mark unanswered questions explicitly rather than allowing bidders to bury them inside estimates.

Give every serious candidate the same information and permit written questions. Ask each one to identify assumptions, exclusions and decisions needed from your team. Their response should distinguish assessment, stabilization, remediation and new development. This makes proposals comparable and exposes vendors that disguise uncertainty behind a single confident estimate.

Specialized systems need additional scrutiny. A predictive maintenance initiative, for example, raises different data and deployment questions from marketing software; see the recovery approach for a predictive maintenance project abandoned by its developers. An inventory system also depends on operational data and measurable decision quality, addressed in the guide to salvaging a stalled AI inventory optimization project.

The best recovery vendor is not necessarily the firm with the most polished AI presentation. Look for a team that can investigate inherited work, communicate uncertainty and make disciplined trade-offs. Ask who will perform the assessment, architecture, implementation, testing and project leadership. Interview the people expected to do the work, not only the salesperson. Request examples of technically comparable responsibilities and ask what evidence existed when major decisions were made.

Trustworthy technology work relies on evidence, transparency, governance, assurance and standards. Those principles are especially important when a successor inherits decisions it did not make. Rohan Hall’s background includes building AI and blockchain systems, leading technology for interoperability and scalable applications, and working across the United States, Europe and Asia. Readers can review Rohan Hall’s ventures, work and publications and the AI-first solutions built and operated by OceSha Ventures for context on that perspective.

If your project depends heavily on labeled data or unfinished model training, use criteria specific to replacing a departed lead on an AI training project. When an off-the-shelf product fails against your data, the right engagement may be diagnosis and customization rather than a replacement platform; the guide to troubleshooting an AI tool that does not fit your data explains that distinction.

Begin with a paid, bounded assessment rather than awarding the entire remaining budget on the strength of a proposal. The assessment should end with tangible outputs: a verified asset inventory, current-state architecture, risk register, reuse decisions, prioritized backlog, delivery options, estimates with assumptions and acceptance criteria for the first implementation stage. You should be able to use those outputs even if you select another implementation team.

Attach payments to accepted deliverables. Require regular demonstrations from a controlled environment and written decisions for material scope changes. Maintain your own copies of current documentation and repositories. Ensure more than one person understands how the platform operates. These controls do not eliminate risk, but they prevent progress from existing only in reports and reduce dependence on a single supplier or individual.

For geographically distributed or partially completed analytics work, the central issue is still evidence and handover rather than location. The case-specific guide to recovering a partly completed AI data analysis project shows how to frame that kind of takeover. Rohan also examines artificial intelligence alongside blockchain, neuromorphic technologies, cognitive intelligence and other emerging technologies in The Convergence of AI and the Top 10 Emerging Technologies, which provides broader context for leaders making technology decisions under uncertainty.

Score finalists against the same criteria: quality of diagnosis, technical fit, treatment of data and security, delivery method, staffing clarity, commercial transparency, documentation and exit readiness. Weight the criteria according to the project’s real risks. If data ownership is uncertain, it should outweigh presentation quality. If a critical system remains live, stabilization experience should outweigh an ambitious feature roadmap.

Ask finalists to walk through a difficult trade-off discovered during assessment. A strong vendor will explain the evidence, available options, consequences and recommendation. It will also identify what your organization must decide or provide. Be cautious when every inherited component is declared worthless without analysis, but be equally cautious when a vendor agrees to preserve everything to avoid challenging your sunk-cost assumptions.