How to take over an abandoned AI project without compounding the risk.

An AI project becomes a rescue problem when the organization can no longer explain, reproduce, operate, or safely change the system while a business or client commitment still depends on it. The trigger may be a key developer leaving, an unresponsive vendor, a proof of concept that works only on one machine, a RAG system that cannot support its answers, an MCP integration with unclear permissions, or an AI workflow that reached production without evaluation and operating ownership.

The first objective is not to improve the model. It is to recover decision-making control. Preserve evidence, establish authorized access, reproduce the current baseline, map the consequences of failure, and decide whether the responsible path is to contain, stabilize, rebuild, hand over, or retire the system.

Recognize the real takeover condition

A weak handover is not just missing documentation. It is a break in accountable ownership. The incoming team needs to know what outcome was promised, which assets exist, who can authorize access and changes, how the current behavior was judged, and what happens to users or clients when the system fails.

The first 72 hours: recover control before changing direction

1. Freeze unreviewed scope and preserve evidence

Stop new features, model swaps, prompt rewrites, index rebuilds, and infrastructure changes until the current state is recorded. Preserve authorized copies of repositories, configuration, deployment history, logs, tickets, architecture notes, invoices, model usage, evaluation results, and known failures. Do not delete a broken path before the team understands what depended on it.

2. Confirm authority and access ownership

Name the business owner, technical owner, security authority, account owner, and person allowed to approve production changes. Inventory code hosts, cloud accounts, model providers, vector databases, data stores, domains, CI/CD, secrets, monitoring, ticketing, and communication channels. Credentials should be transferred or rotated through approved controls. Avoid a broad uncoordinated rotation that destroys access or evidence unless an active compromise requires immediate containment.

3. Reproduce the current baseline

Use a clean, authorized environment to run the smallest complete path from input to output. Record versions, configuration, data snapshot, retrieval behavior, tool calls, latency, cost, logs, and manual interventions. A baseline can be bad; it still needs to be reproducible before the team can prove that a rescue change helped.

4. Map the blast radius

Identify users, client commitments, downstream systems, customer communication, regulated data, financial or operational actions, and scheduled workflows affected by failure. Separate read-only assistance from actions that write data, send messages, grant access, or make commitments. Consequence determines what must be disabled, supervised, or escalated immediately.

5. Choose a controlled decision path

Do not default to a rewrite. Compare the current system against the actual business outcome, security boundary, operating model, and available evidence. Choose the smallest path that restores responsible ownership.

AI project handover checklist

Use this checklist to distinguish known facts from assumptions. A missing item is not automatically a failure, but it must become an explicit risk, owner, and next action.

Business commitment and decision ownership

• Expected business outcome, users, client promise, deadline, budget boundary, and current consequence.
• Named commercial owner, technical owner, security approver, production-change approver, and acceptance owner.
• Original scope, changes already promised, unresolved disputes, and decisions that are waiting.

Code, environments, and deployment

• Repositories, branches, uncommitted work, dependencies, licenses, build instructions, CI/CD, artifacts, and release history.
• Development, test, staging, and production environments with ownership, configuration, regions, limits, and dependencies.
• Current deployed version, rollback path, feature flags, scheduled jobs, queues, background workers, and manual release steps.

Models, prompts, and application behavior

• Model providers, model IDs, versions, routing, fallback, temperature or reasoning settings, token limits, and cost assumptions.
• System instructions, prompt templates, structured-output schemas, examples, guardrails, and where configuration is stored.
• Known model limitations, prohibited use, rate limits, retry behavior, and changes that previously caused regressions.

Data, retrieval, and RAG

• Source systems, ownership, permissions, data classification, freshness, ingestion, chunking, metadata, embeddings, and indexes.
• Retrieval queries, filters, tenant boundaries, ranking, citation behavior, deletion, re-indexing, and stale-data handling.
• Representative questions, expected sources, unsupported-answer policy, conflicting sources, and no-answer behavior.

Tools, integrations, agents, and MCP

• APIs, MCP servers, tools, actions, authentication, authorization, schemas, timeouts, retries, rate limits, and idempotency.
• Which operations read, write, delete, send, approve, or create commitments in another system.
• Agent stop conditions, iteration limits, human approval, state persistence, replay, and recovery after partial completion.

Evaluation and acceptance evidence

• Evaluation datasets, source cases, expected behavior, rubrics, automated checks, human review, and baseline results.
• Critical failure categories, release thresholds, known edge cases, model comparisons, and regression history.
• Who can approve quality, how disagreements are adjudicated, and which failures require escalation or shutdown.

Security, privacy, and access

• Named accounts, secrets ownership, least privilege, audit logs, environment separation, retention, deletion, and revocation.
• Prompt injection exposure, tool authorization, data exfiltration paths, sensitive logging, third-party subprocessors, and incident contacts.
• Contractual data restrictions, client approvals, regulated information, and evidence of previous security review.

Operations, monitoring, and economics

• Availability, latency, errors, task completion, evaluation drift, human edits, escalations, model usage, and infrastructure cost.
• Alerts, dashboards, logs, traces, support hours, issue queues, incident procedure, known workarounds, and service dependencies.
• Runbooks, change control, backup, restore, rollback, capacity assumptions, provider limits, and operating budget.

RAG rescue: separate retrieval failure from model failure

A RAG project often appears to have a model-quality problem when the actual failure is elsewhere. Test source coverage, ingestion freshness, parsing, chunk boundaries, metadata, permissions, embedding consistency, query construction, filters, ranking, context assembly, citations, and no-answer behavior separately. Use representative questions with expected sources so the team can see whether the correct evidence was available before judging the answer.

Do not rebuild the index merely because results are poor. Record the current configuration and run a small diagnostic set first. An index rebuild can erase the evidence needed to understand whether the regression came from source data, parsing, metadata, embedding changes, retrieval logic, or model behavior.

Claude and MCP rescue: inspect authority, not only connectivity

A Claude or MCP integration is not ready because a tool call succeeds. Confirm which user or service identity the tool represents, what resources it can see, what actions it can perform, how arguments are validated, whether tenant boundaries hold, what is logged, and where human approval is required. Read operations, write operations, destructive actions, and external communication should not share an implicit authority model.

Capture the complete path from Claude request to MCP server, downstream API, result, model response, and any resulting action. This makes partial failures, duplicate execution, permission escalation, stale schemas, and hidden manual steps visible.

Communicate the rescue without overpromising

For an IT service firm or agency, the technical rescue and the client relationship are inseparable. Report known facts, current impact, containment, missing access, next evidence, decision owners, and the next review point. Avoid announcing a rebuild, recovery date, or root cause before the current behavior and dependencies are reproducible.

When Datrick works behind another provider, the partner retains the account, commercial commitments, priorities, and final client-facing approval. The operating model is described in the white-label AI delivery guide.

Acceptance criteria for a successful takeover

• An authorized second person can build, deploy, run, observe, and stop the system without relying on private memory.
• Repositories, environments, data, model accounts, integrations, domains, and credentials have named owners.
• The current baseline and critical failure cases can be reproduced against a controlled evaluation set.
• Production actions have explicit authority, human-review, logging, rollback, and escalation boundaries.
• Known risks, missing evidence, technical debt, costs, limits, and temporary controls are documented.
• The business owner can choose stabilize, rebuild, continue, or retire using written evidence.
• A runbook identifies support ownership, monitoring, incident response, change approval, and handover status.

For the target operating state after stabilization, use the production-ready AI workflow guide. The database handover checklist also provides a useful ownership pattern for systems, access, backups, dependencies, and escalation.

Frequently asked questions