An AI tool can look autonomous because it responds without pause, but it never sustains itself. Someone prepares sources, removes data that should no longer be there, notices an answer that hurts, explains a decision to a person who cannot understand it, and changes a rule when context moves. That work is often spread through short moments and invisible names. When it is not acknowledged, an organisation buys a promise of automation and hands its people a maintenance obligation without time or recognition.
Name the chain of care#
A maintenance notebook needs no new platform. It can be a shared document with five columns: what happened, who was affected, what was corrected, who decided, and when it will be revisited. The essential step is recording small interventions too. If an educator rewrites a suggestion every morning so it does not exclude a pupil, that is not an anecdote. It is evidence that the system needs another boundary, another source, or perhaps another use.
A maintenance notebook needs no new platform. It can be a shared document with five columns: what happened, who was affected, what was corrected, who decided, and when it will be revisited.
At a neighbourhood clinic, an assistant helps summarise internal notes and never decides treatment. Every Thursday, the responsible person reviews three samples and writes what information was absent and which sentence could mislead. Over time the notebook shows patterns: the assistant works well for administration but confuses dates when referrals move between services. That observation supports restricting use and requesting a precise improvement rather than waiting for a serious incident to expose the weakness.
Maintenance deserves resources#
Recognising invisible work means assigning hours, training, and a route to stop use. It is unreasonable to ask someone to supervise a complex tool “on top of their job” without authority or a calendar. A mature organisation counts that time before calling the result a saving. It also distributes the burden: the person who detects an incident should not always investigate it, communicate it, and absorb the affected person's distress.
The notebook has another purpose: it preserves memory as people change. Without it, every handover discovers the same risks again and responsible decisions depend on the goodwill of whoever happens to be on duty. With it, a new colleague can understand why a rule exists, which harm it avoided, and when it needs review. That continuity is more human than delegating trust to a brand or a commercial promise.
Open a notebook for an AI use that is already operating, not for the ideal project. For two weeks record one correction each day, however small, then ask what the list requires: more time, a boundary, an accountable person, or a decision to switch off a feature. Caring for technology starts by caring for those who maintain it.
Maintenance needs permission to stop#
Recording an incident achieves little when nobody can decide what to do about it. That is why a notebook needs a stopping threshold, not merely a list of fixes. A team might agree that three answers corrected for the same reason, one complaint involving sensitive data, or a week without review requires the function to pause until it is discussed. A threshold does not punish the person noticing trouble. It gives them permission to say that speed no longer compensates for the risk. Without that authority, the person maintaining the system learns to solve problems silently, while the organisation mistakes their effort for the tool’s reliability.
A small team can share this responsibility without building a new office. The user records the case; another person reviews the pattern; and the coordinator has protected time to decide whether to correct, limit, or pause it. Rotation matters: when one person always reviews, their knowledge becomes indispensable and hard to question. In a youth-guidance project, for example, a weekly note may reveal that suggestions call transport difficulties a lack of commitment. The responsible decision may be to remove that suggestion, explain the change, and ask the team for an alternative that does not flatten a complicated circumstance.
Open a one-page notebook this week and record the latest moment when somebody had to intervene. Do not start by asking whether the model was correct; ask what human care was needed to make its answer acceptable. Date the next review and name who may stop use if similar signals appear. Making that work visible does not diminish the technology. It prevents care, correction, and responsibility from being spent without recognition until only an unsustainable promise remains.
Keep decisions, not only errors#
A notebook gains value when it records why a decision was made, even when no dramatic failure occurred. It can note that human review remained because a case was ambiguous, that a source was reduced because it aged badly, or that a feature was rejected because nobody could explain it to affected people. Those notes create memory for whoever arrives next. Without them, every change looks like personal preference and the team begins each discussion from zero. With them, a decision can be reviewed respectfully: its context is understood, its continued validity is tested, and it changes when better reasons appear.
Reserve a short but real moment to read the notebook aloud. There is no need to review the entire system: two incidents and one pending decision are enough. Ask which person took on extra work, which signal should trigger a pause, and what can be clearly explained to people using the service. Then publish a simple version of what was learned for the team itself. Maintaining responsible AI does not mean heroically watching a machine. It means giving time, authority, and memory to the people who notice limits before those limits fall on somebody with less room to respond.
Care can be shared#
Making maintenance visible also allows it to be shared fairly. When one person corrects, documents, and explains, their absence becomes a risk and their knowledge sits outside formal decision-making. A simple calendar can rotate who reads incidents, who prepares review, and who communicates a change. This does not dilute responsibility; it ensures several people can recognise a limit and act. Once work is distributed, questions emerge that an individual routine would have missed, and corrections stop depending on heroic availability.
An organisation can support that sharing with small but real decisions: reserve time in calendars, count review as work, and thank someone who proposes a pause. It can also invite an affected person to check whether the resulting explanation is understandable, without asking them to perform technical labour. That outside view recalls that the goal is not keeping a tool running at any price. It is maintaining a service relationship where errors are recognised, responsibilities have names, and people retain a clear way to ask for another answer.
The notebook can also protect an honest conversation with the people funding or leading a project. Instead of presenting automation as a closed promise, the team can show which interventions remain necessary and which resources they require. That clarity makes it possible to assign time, limit scope, or change direction. Hiding maintenance may make an initiative look cheap for a while. Naming it allows the work to remain cared for, understandable, and sustainable once it is no longer new.
A notebook earns trust when its entries lead to a visible choice: change a source, fund review time, narrow a task, or stop it. Recording without a response merely documents exhaustion.
