The pilot ends and the obligations do not
A pilot succeeds, the team is redeployed, and the system stays. It keeps running because nobody may switch it off, and badly because nobody is responsible for it. A chief information officer who signs this off has accepted an obligation without a mechanism.
Maintainability is decided in the pilot, not after it. Almost every property that determines whether a system can be handed over is either present at the end of the pilot or expensive to add later: a named owner, a test suite, versioned rules, a monitoring signal and a dependency list. A pilot built to demonstrate a capability cannot be handed over.
Ownership has to be a job, not a project
Ownership of an AI system is usually assigned to a sponsor who has moved on, to the team that built it, or to nobody. None of those is maintainability. A maintainable system has a named operational owner accountable for its behaviour, and a business owner accountable for what it decides.
The distinction matters because the work between them is continuous. The engineering owner handles degradation, dependency failures, model or prompt changes and deployment. The business owner handles rule changes, the definition of a case and the escalation of a repeated exception. A system with only one of the two is unmanaged or governed by people who cannot change it.
Write the test suite in business language
AI systems degrade silently because nobody can tell when they have. A conventional system fails loudly when a dependency changes; a system that reads a document and proposes an action can drift into uselessness while every component reports itself healthy. The protection is a test suite in business language, run on a schedule.
Such a suite need not be large. A set of representative cases taken from real historical records, with the expected outcome agreed by the business owner, catches most of what matters: a change in input format, a schema change upstream, a rule amended in a hurry, a source system that now returns an empty result.
Version the rules as carefully as the code
Business rules live in a strange place. They are often expressed in prompts, in configuration, or in the accumulated judgement of the person who wrote the logic, and they change far more often than the code around them. A threshold moved during a busy month, a condition relaxed to clear a queue, a definition quietly updated in a spreadsheet: each is small, and each changes what the system does.
The treatment that makes this manageable is to hold rules as data with a version, a severity, an owner and an effective date, evaluated through one interface so a decision can always be explained by the rule set in force at the time. Our renewal demonstration does this with a small numbered rule set, each rule versioned and attributed, and every evaluation capturing the outcome and the records it read. The wider discipline is in continuous testing and change management.
Monitoring tells you when the world has changed
Traditional monitoring watches whether the system is running. For an AI-enabled workflow that is the weaker half of the job. The other half watches whether it is still doing something useful, and the signals that matter are about the inputs: the volume arriving in each source, the proportion of records rejected, the rate of exceptions raised, and the age of the oldest unresolved item.
A rising exception rate with flat volume is a definition problem. A falling volume with a flat rate is a source problem. Both look like noise in a component dashboard, and both are obvious in a measure of the process. Monitoring should therefore be defined against the process, and somebody should look at it on a schedule.
Documentation is the first thing the next engineer reads
The documentation that matters is short and specific: what the system is for, what it may not do, what it depends on, how to change a rule, how to re-run a failed run, how to roll back, and who to call. Written at the end of the pilot, it decides whether handover takes a week or a quarter.
Two things are usually missing. The first is the dependency list with owners, because the pilot team knew which upstream changes would break the system and that knowledge is written down nowhere. The second is the decision log: why a rule is the way it is, and what would justify revisiting it.
A sequence for the first quarter after handover
- Name the operational owner and the business owner, and put them in the same review meeting with a fixed agenda and a written outcome.
- Assemble a regression set from real historical cases, agree the expected outcomes with the business owner, and schedule it to run on every change.
- Move the business rules out of prompts and configuration into a versioned set with owners and effective dates, and publish the current version to the people affected by it.
- Define the process-level monitoring measures and the exception queue, and put both on a weekly review with a named reader.
- Write the handover document while the pilot team still remembers: the dependency list, the decision log, the rollback procedure and the support path.
The measures for the first year are the ones a new operator would use: how long a failure takes to detect, how long to correct, how many changes were made without a test, and how often the exception queue was reviewed by its named reader.
None of this is exotic engineering, and that is the point. A system that behaves this way is maintainable by an ordinary product team, and the alternative is one only the original authors can safely touch. The design decisions behind it are set out in from business requirements to structured applications and in moving from a chatbot to business execution. The conditions for keeping the capability rather than the project are in building reusable enterprise AI capabilities.