What Happens When the Consultant Leaves

The dependency trap

You hired a consultant to build AI. They built it. It works. They leave.

Three months later, the model drifts. Accuracy drops. Nobody knows why. Nobody knows how to retrain it. Nobody knows where the training data lives.

You call the consultant. They’re “available for a retainer.” €8K/month. To maintain a system you paid €150K to build.

This isn’t a bug in the engagement. It’s the business model. Build something you don’t own, then charge you to maintain it forever.

I’ve seen this pattern repeatedly. It’s the most common outcome of AI consulting engagements - and the least discussed. Nobody writes case studies about the system that became a hostage.

How to spot a vendor who’s building dependency

The signs are visible from day one if you know what to look for:

They don’t document. Or they document in a way only they can understand - internal jargon, undocumented assumptions, references to conversations that happened in Slack.

They don’t train your team. “Your team isn’t ready for this yet” is a stall, not a plan. If they can’t tell you when your team will be ready and what training will get them there, they’re not planning to leave.

They use proprietary tools or frameworks that only they can operate. Custom wrappers, private libraries, internal platforms. If the tool has their company name on it, you can’t use it without them.

They hold the deployment keys. You can’t deploy without them. You can’t change a prompt without them. You can’t update the model without them.

They don’t have a handover plan. Or the “handover plan” is a 2-hour call and a PDF that nobody will read after the call.

If you see any of these signs, you’re not building a capability. You’re building a dependency.

What “real handover” looks like

A real handover isn’t a meeting. It’s a set of artifacts and a process that starts on day one of the engagement:

Documentation: Architecture diagrams, data flow maps, model cards, decision logs. Written for your team, not for the consultant. If your lead engineer can’t understand the documentation, it’s not documentation - it’s a prop.

Code: In your repository, with your CI/CD pipeline, with your access controls. Not in the consultant’s private repo. Not in a shared workspace they control. Your repo. Your rules.

Runbooks: What to do when the model drifts. What to do when accuracy drops. What to do when the API changes. What to do when latency spikes. Step by step. Not “call us” - actual steps your team can execute.

Training: Your team shadows the consultant during the build. They attend standups, review code, ask questions. They’re not just watching - they’re learning. By the time the consultant leaves, your team has been running the system for weeks.

Ownership: You own the code, the data, the models, the documentation. All of it. No exceptions. No “we’ll give you the code after final payment.” No “the model is ours but you can use it.” Yours.

The team you actually need

You don’t need a team of AI researchers. You need three people you probably already have:

An AI owner - an existing engineer, promoted or trained. They understand the system, can debug issues, can coordinate with vendors if needed. They don’t need to be an AI expert. They need to be the person who knows how the system works and who to call when it doesn’t.

A data person - an existing data analyst or engineer. They manage data pipelines, monitor quality, handle retraining. They’re already working with your data. Now they’re working with the data that feeds the AI.

A product owner - an existing PM or business lead. They own the business outcome, track metrics, prioritize improvements. They’re the person who says “the AI is saving us 30 hours/week” or “nobody’s using it, we need to fix the workflow.”

That’s three people. They don’t need PhDs. They need training, documentation, and ownership.

If a consultant tells you “you need to hire an AI team,” ask them what specifically each person would do. If they can’t explain it clearly, they’re upselling.

The phased handover model

A proper handover happens in phases, not in a single meeting at the end:

Phase 1 (during build): Your team shadows. They attend standups, review code, ask questions. They’re not building - they’re learning. But they’re in the room.

Phase 2 (pre-deployment): Your team runs the system with the consultant present. They make changes, deploy updates, handle issues. The consultant reviews but doesn’t do. Your team is driving with a driving instructor in the passenger seat.

Phase 3 (post-deployment): Your team runs it alone. The consultant is available for questions but not for operations. 30-day check-in. 90-day final review. The consultant is the safety net, not the driver.

Phase 4 (independence): Your team owns everything. The consultant is gone. The system runs. If something breaks, your team fixes it. They have the documentation, the runbooks, and the knowledge.

If a consultant won’t commit to this phased model, they’re not planning to leave. They’re planning to stay - on your payroll.

The cost of dependency vs. the cost of capability

Dependency: €8K/month retainer × 36 months = €288K. Plus the original build cost. Plus the cost of being unable to make changes without the vendor. Plus the cost of being unable to switch vendors because nobody else understands the system.

Capability: Training 3 existing team members = €15-30K one-time. Plus documentation (included in build). Plus ongoing salary (you’re already paying them).

The math isn’t close. Dependency costs 10x more than capability. And capability means you can fire the consultant.

Questions to ask before you sign

1. “Who owns the code and models after the project?” You do. In writing. Not “you have a license” - you own it.

2. “What documentation do we receive?” Architecture, data flow, model cards, runbooks. Written for your team.

3. “How is our team trained during the project?” Shadowing, hands-on, phased ownership. With a timeline.

4. “What happens if we want to switch vendors mid-project?” You can. Everything is in your repos. No lock-in.

5. “What’s the handover process?” Phased. With a timeline. With success criteria. Not a 2-hour call.

If the answers are vague, the handover will be vague too.

What I do

My engagements include handover from day one. Your team is in the room during the audit. They shadow during the build. They run the system before I leave.

I provide documentation, runbooks, and training. I commit to a phased handover with a fixed end date.

I charge for the project, not for the dependency. When I’m done, I’m done. If you want me back, it’s a new engagement - not a retainer. You call me because you want to, not because you have to.

FAQ

What if our team is too small? Three people is enough. If you have fewer, we discuss fractional ownership models - shared responsibilities across roles. The key is that someone owns the knowledge, not that you need a dedicated AI team.

What if we want ongoing support? Available. But as project-based engagements, not retainers. You call me when you need me, not when you’re forced to. There’s a difference.

What if the system breaks after you leave? Your team has runbooks. If they can’t fix it, call me. It’s a new engagement - scoped, priced, and temporary. Not a hostage negotiation.