8 min. read

Go-live day goes well. The forward deployed engineer walks the sponsor through the system, leadership thanks the team, and two weeks later the vendor’s people roll off to their next customer.

Three months after that, the AI’s answers start drifting. A vendor update changes how a feature behaves. A second business unit wants in. And nobody inside your organization is sure who to call, because the person who understood the system best never worked for you.

This post covers what leaves with a vendor’s FDE, why AI needs an owner after go-live even more than traditional software does, and a 90-day plan for handing the system to someone who stays.

Go-live is the middle, not the end

Traditional enterprise software settles down after launch. AI systems don’t, for three reasons.

Models degrade. A 2022 study in Scientific Reports tested four standard machine learning model types across 32 datasets from four industries and found quality degrading over time in 91% of cases, sometimes slowly and sometimes in sudden drops. That study covered conventional models, not large language models, but the lesson carries: a system that worked at launch has to be watched to keep working.

Vendors change the system under you. Hosted AI products get new model versions, retired features and changed defaults on the vendor’s schedule, not yours.

Your business changes too. In MIT’s Project NANDA research, one executive explained that their processes change every quarter, and a tool that can’t keep up sends people back to spreadsheets. The buyers who succeeded treated deployment as an ongoing partnership and stayed with it through early failures. MIT also found enterprises locking in AI vendor relationships that will be hard to unwind, because a system trained on your workflows gets more expensive to replace every month.

Put those together and an AI system needs an owner for its whole working life, not just the build. The build is the part the FDE covers.

What leaves with the FDE

When a vendor’s engineer rolls off, the code stays. A lot of the understanding doesn’t. Typically, what walks out the door includes:

The reasoning behind design decisions: why this data source, this threshold, this workflow
The integration map: what connects to what, under which credentials, approved by whom
The tuning: prompts, configurations, evaluation tests and the known edge cases
The relationships: who to call on the vendor’s product team, and how to escalate
The ground truth about what users actually do, as opposed to what the spec said they would
The quiet fixes that solved real problems and never made it into the documentation

Your entry could not be saved. Please try again.

We sent links to your email! You should have received an email from us already. If you did not receive, make sure you check your spam folders and add masterofproject.com to safe senders list to receive our emails.

Documentation captures some of that. It never captures all of it.

A legacy lesson: relearning the F-1 engine

The Saturn V’s F-1 engines took Apollo to the moon, and their diagrams survived. When NASA wanted to learn from the F-1 again decades later, that wasn’t enough. In 2012 and 2013, a small team of young engineers at Marshall Space Flight Center took F-1 engines apart, pulling gas generators from engines stored at Marshall and at the Smithsonian. They refurbished a gas generator and test-fired it, recording data with modern instruments that the 1960s tests never captured. Several of them hadn’t been born when the last Saturn V launched.

The diagrams were there. The working knowledge had to be rebuilt by hand. NASA had decades to plan for that kind of gap. A typical AI handoff has a couple of weeks.

The unplanned version: when the vendor leaves

An FDE rolling off is the planned version of losing your vendor’s knowledge. The unplanned version is the vendor itself disappearing. Builder.ai, a London AI app-building startup, attracted as much as $445 million from investors including Microsoft and the Qatar Investment Authority. In May 2025 it ran out of money and entered insolvency. Every customer whose product depended on its platform inherited the problem.

Most vendor exits are far less dramatic. The question is the same either way: what do you own, and who on your side understands it?

Who owns what after go-live

Here is the work that starts when the vendor’s team leaves, who usually ends up with it by default, and who should own it.

After go-live, someone must…	Typical default	Better owner
Monitor quality and drift	Nobody, until users complain	A named deployment owner, against agreed metrics
Manage vendor updates and model changes	The vendor	Your owner, through change control
Handle incidents and escalations	The IT help desk	Your owner, with the vendor escalation path in writing
Train new users and teams	The original champion, if they’re still there	Your owner, working with L&D
Decide the next use case	Whoever asks loudest	Your owner, through the PMO’s portfolio process
Hold the vendor to the business metric	Procurement, at renewal time	Your owner, every quarter

Notice that the right-hand column keeps naming the same person. That’s the point.

A 90-day handoff plan

Knowledge transfer scheduled for the FDE’s last week rarely happens. Start three months out. If you’re earlier in the process, begin with the seven questions to ask before an FDE arrives.

90 to 60 days before the FDE leaves

Name the receiving owner. One person on your payroll, assigned before the FDE leaves, not after.
Put the owner in the room. Daily standups, design decisions and vendor calls, starting now.
Inventory everything. Every integration, credential, data flow and configuration, with an owner next to each.

60 to 30 days out

Reverse the roles. Your owner runs the system while the FDE watches and corrects.
Build the evaluation set. The test cases that prove the system still works, plus the drift thresholds that trigger action.
Write the escalation path. Named vendor contacts, response times and what counts as urgent.

The last 30 days

Run an incident drill. Break something on purpose, in a safe environment, and let your owner fix it.
Capture the why, not just the what. A decision log explains choices that documentation only records.
Agree on hypercare. The vendor’s post-exit support window, and the date your owner formally signs off.

After the FDE leaves

Monthly: quality and drift review against the evaluation set.
Every vendor release: change control before updates reach users.
Quarterly: vendor review against the business metric the system was bought to move.

The same closeout discipline applies to governance work; we cover it in our playbook on closing out a governance project and handing it to operations.

Who should be the receiving owner?

Not a committee, and not IT alone. The receiving owner has to work across the vendor, the data and IT teams, the business unit and the people using the system, and keep doing it after every vendor has gone. That’s the job of an AI project manager. We compare the role with the vendor’s engineer in detail in FDE vs. in-house AI project manager.

Since September 8, 2026, there has been a registered way to build that person. The Maryland Apprenticeship and Training Council registered MATC Program #2575, the first Registered Apprenticeship in the United States dedicated to AI project management, sponsored by Master of Project Academy and announced via Business Wire.

The timing fits a handoff well. Apprentices are full-time W-2 employees of their employer from day one and contribute to live AI initiatives from their first week of on-the-job learning. If you hire one while the vendor’s FDEs are still on site, your apprentice learns the system alongside them and is still on your payroll when the vendor rolls off. Over the 24-month term, they complete 4,000 hours of mentored on-the-job learning across eleven registered work processes, including AI System Integration & Governance. They also complete 340 hours of related instruction, 259 of them AI-specific, and earn five stackable credentials: CAPM, PMP, an AI Specialization, the Apprenticeship Certificate of Completion and 60 PDUs.

Employers in Maryland and Pennsylvania can participate today, and recognition in additional states is in progress. See how employers join the apprenticeship, or read the AI project management apprenticeship FAQ.

Frequently asked questions

What should an AI vendor handoff include?

At minimum: a named internal owner, an inventory of every integration, credential and configuration, an evaluation set with drift thresholds, a decision log, a written escalation path with the vendor, and an agreed hypercare period with a formal sign-off date.

How long should knowledge transfer from a forward deployed engineer take?

We recommend starting about 90 days before the FDE leaves, with your owner running the system under the FDE’s supervision for the final 30 to 60 days. Knowledge transfer squeezed into the last week rarely sticks.

Why does AI need an owner after go-live?

Because AI systems keep changing after launch. Models degrade over time, vendors update the underlying models and features, and your own processes shift. Someone has to monitor quality, manage those changes and hold the vendor to the business result.

Have an owner ready before the vendor leaves.

A 30-minute curriculum review scopes your vertical, your cohort size and which incentives apply in your state.

Book a 30-minute curriculum review →

About Master of Project Academy

Founded in 2012, Master of Project Academy has trained 500,000+ learners across 180+ countries in project management, with a 99.6% first-attempt PMP pass rate in delivered cohorts. Master of Project Academy is the registered sponsor of MATC Program #2575, the nation’s first AI Project Management apprenticeship. Learn more at masterofproject.com/p/aipmapprenticeship.

Sources

The FDE Leaves: Who Owns Your AI After Go-Live?