Your team has just closed its first enterprise AI deployment. For three months, your engineers worked inside the customer’s environment. A developer wrote rules for the records the pipeline could not parse. An operations lead explained what each status code meant. The customer’s data team agreed on the cases the model had to get right. The project went live, and the closing deck summarized the work in a dozen slides.
Then a second customer signs. Same industry, similar use case. The team opens the deck, and the work starts over: someone writes the exception rules again, someone explains the codes again, someone builds the test cases again.
Your second AI project should inherit more than a slide deck. It should inherit the first project’s data preparation and validation in a form the next team can run, read, and check, while the judgment that belongs to one customer stays with that customer.
Key takeaways
- A first AI deployment leaves three kinds of knowledge beyond the working system: exception handling, business context, and validation criteria. Most of it lives in scripts, meeting notes, and spreadsheets.
- Sort each piece of work into keep, carry, or recheck: what stays with the customer, what your software carries forward, and what the next team verifies first.
- A handoff package holds what the next team can run: the approved data version, preparation code, validation cases with results, open exceptions with expiry dates, and who confirmed each definition.
- Reused preparation still needs fresh validation when the task, the model, or the policy changes.
What a first AI deployment actually leaves behind
A first enterprise AI deployment produces three kinds of knowledge beyond the working system: exception handling, business context, and validation criteria. Most of that knowledge comes from the data work, and most of it never gets written down.
- Exception handling. A developer writes a rule for records that break the parser: a date field stored in two formats, a customer ID that changed after a merger. The rule lives in a script one person has run.
- Business context. An operations lead explains that Status 7 indicates closed but disputed, or that a blank amount means nobody has issued the invoice yet. The explanation lives in a meeting note.
- Validation criteria. The customer’s data team agrees on the cases the model must get right before go-live. The list lives in a spreadsheet attached to an email.
The customer got a working system. Your company got experience, and most of that experience now sits with the people who did the work: the forward deployed engineers, the delivery lead, the one developer who remembers why a rule exists.
Why AI data preparation rarely reaches the next project
AI data preparation rarely reaches the next project because the first team keeps it in scripts, meeting notes, and spreadsheets that a new team cannot run or check. A closing deck can explain what the team did, but the next team cannot rerun a slide. When the second project starts, the scripts sit in a repository nobody on the new team has opened, the meeting notes describe codes the new customer does not use, and the spreadsheet of test cases answers questions about a different business.
Because every customer’s environment is different, delivery teams find it easy to accept the repeat work as inevitable. A second customer does bring different fields, different exceptions, and a different definition of a correct answer, so teams start to assume that nothing transfers. Some of the work should start again. The rest repeats on every project, and that is the part worth keeping.
Industry surveys show the same stall between a first success and wider use. In an S&P Global survey of 1,006 IT and business leaders in North America and Europe, conducted in late 2024, companies reported scrapping 46% of AI proofs of concept on average before production. In McKinsey’s 2025 State of AI survey of 1,993 respondents in 105 countries, about two-thirds said their organizations had not yet begun scaling AI across the enterprise. In Kyndryl’s 2025 Readiness Report, which surveyed 3,700 leaders in 21 countries, more than half said innovation projects often stall after the proof of concept.
Investors who back services-heavy AI companies make a similar point. In a June 2025 essay for Andreessen Horowitz, Joe Schmidt argued that hands-on deployment work pays off once it turns into shared software libraries and clear documentation.
Keep, carry, recheck: sort the first project’s work
The keep, carry, recheck split sorts each piece of first-project work into three groups: what the customer keeps, what your software carries to the next project, and what the next team rechecks before relying on it. To place a step, ask whether the next customer will need the same kind of step, even when the values differ. If the answer is yes, the step belongs in software your team can run again. The specific values usually stay with the customer. Sorting goes faster when the team has already defined the work at the level the AI must execute.
| Work from the first project | Keep: stays with the customer | Carry: moves to the next project | Recheck: how the next team verifies it |
|---|---|---|---|
| Field definitions and business terms | The meaning of this customer’s codes and statuses | A place to record what each field means and who confirmed it | Ask the new customer’s owner to confirm or replace each definition |
| Exception rules | The specific exceptions and how long each one applies | A standard way to record an exception with its scope and expiry date | Check which exceptions still apply and drop the expired ones |
| Data preparation steps | Source-specific joins and mappings | Preparation steps kept as code, with inputs and outputs recorded | Rerun the steps on a sample of the new data and compare the output |
| Protection conditions | Which fields this customer treats as sensitive | A repeatable way to protect sensitive fields while keeping the structure the task needs | Confirm the new customer’s policy and test that the task still works after protection |
| Validation criteria | The test cases and pass thresholds for this use case | A test harness that runs cases against a fixed data version and records results | Write new cases for the new task and rerun the harness |
| Evidence of what passed | The approval decision | A record linking the data version, the model or agent, the evaluation conditions, and the result | Revalidate when the data, the model, or the policy changes |
The carry column is what your team can turn into repeatable software. The recheck column tells the next team what to verify before anyone relies on it.
Start with the AI deployment challenges that broke the first project
The AI deployment challenges that broke the first project are the ones most likely to repeat, so a delivery lead should package them first. Few delivery leads have time to package everything, and the steps that caused delays, rework, or wrong answers carry the most value for the next team.
- Records that broke the pipeline. Keep the parsing and exception rules as code, with a sample of the records that triggered them.
- Definitions that produced wrong answers. When the model misread a field, record what the field meant, who explained it, and the case that exposed the mistake.
- Validation cases the model failed at first. Those cases describe the edges of the task better than any summary, and the next customer will have similar ones.
Take one exception as an illustration. Suppose the first customer allowed a supplier to submit invoices without a purchase order number for one quarter. If the team records that rule with its scope and end date, the second project sees it as an expired, customer-specific exception. If the rule lives only inside a preparation script, the second project may apply it as if it were a general rule. AI summaries cause the same failure when they drop an exception’s scope and end date.
What an AI project handoff package should contain
An AI project handoff package gives the second team the first project’s evidence along with its output, in a form the team can open on day one. Most delivery teams already hold a knowledge transfer session at the end of a project. The session covers what people remember. The package covers what the next team can run. A useful package holds five things.
- The data version the customer approved, with a record of how the team prepared it.
- Preparation steps as runnable code, with the inputs and outputs of the last run.
- The validation cases, the pass thresholds, and the result for each case.
- Open exceptions, each with its scope, owner, and expiry date.
- A list of who confirmed each business definition, so the next team knows whom to ask.
The deck tells the story of the project. The package gives the next team something to rerun and something to argue with when the new customer’s data looks different. When a score drops later, the same records help the team narrow down what actually failed. They also help whoever approves AI output on the next project: a reviewer who can see the source, conditions, and exceptions behind a draft does not have to rebuild them by hand. We covered that review step in why reviewing AI drafts takes so long.
Reused AI data preparation still needs validation for each new use case
Reused AI data preparation needs fresh validation whenever the task, the model, or the policy changes. Carrying work forward does not make the first customer’s preparation fit every AI task that follows. Preparation that suited a claims triage model may not suit a fraud model built on the same tables. A test harness says nothing about a new task until someone writes cases for it.
Treat each reused step as a starting point. When the task, the model, or the policy changes, validate the fit again with the model or agent you plan to use, under evaluation conditions you fix in advance. Sometimes the result comes back inconclusive, and the team needs more cases before anyone decides. This is the practical side of AI-ready data: data counts as ready for a specific task, model, and set of criteria, and it stays ready only while those checks keep passing. Skipping that step produces the drift pattern described in Why AI Fails After Deployment.
Keep the repeatable part in Syntitan
CUBIG builds Syntitan, an AI-Ready Data Platform, for teams that prepare and validate enterprise data for AI across many projects. Syntitan keeps the repeatable part of that work as software. Teams assess data readiness, prepare data for a defined use case, validate the fit with the model or agent they chose, and release a data version linked to the conditions it ran under. A team can start at the data preparation stage and add validation and release as the work grows.
The delivery team still owns the customer relationship, the business definitions, and the final approval. Syntitan records what the team prepared and what passed, so the second project starts from evidence the team can check.
Run the second-project test before you close the first
Five questions for the last week of a deployment:
- Could another engineer rerun our data preparation without asking the person who wrote it?
- Does every exception we added have a scope and an expiry date?
- Can we show which data version passed validation, and under which evaluation conditions?
- Do we know which business definitions a new customer must confirm again?
- If the model changed tomorrow, would we know what to revalidate?
If most of your answers are no, the first project may have delivered a working system but left behind little the next team can build on. Packaging the work during the last week of the first deployment is easier than reconstructing it at the next kickoff.
If your team delivers AI projects across customers and wants data preparation and validation to carry forward, explore Syntitan.
