By Greg Nowak. Updated 3 November 2026.
Imagine someone builds a script to reconcile two exports. It saves time, gets shared, and becomes part of the Friday routine. Then its creator goes on holiday, a column changes, and nobody knows whether the latest report is complete.
That is when a useful experiment reveals an operational gap. Once colleagues or customers depend on an AI-built tool, someone needs responsibility for its output, access, maintenance, and recovery. For a small business or agency, that can start with a named owner and a short operating note.
When does an experiment need an owner?
Assign ownership when other people use the tool repeatedly, it runs unattended, it connects to business systems, or its output influences decisions. A small script that updates customer records deserves more attention than a large prototype nobody relies on.
Start by asking which homemade tools keep work moving. Include spreadsheets, reporting scripts, integrations, and small internal apps. Explain that the purpose is to support useful work; people need to feel comfortable showing you something unfinished.
| How the tool is used | Who takes responsibility | First practical step |
|---|---|---|
| Personal experiment with no dependent process | Its creator | Record its purpose and keep experiments away from live changes. |
| Shared report or repeatable team task | Business owner and technical contact | Store code centrally and define a correct result. |
| Scheduled integration between systems | Owner, technical contact, and backup | Check credentials, failure alerts, and missing runs. |
| Changes records or supports consequential decisions | Owner with authority to pause use | Require proportionate review, output checks, and tested recovery. |
Separate business ownership from technical support
The business owner decides what the tool is for, who should use it, and what acceptable output looks like. They also decide when to pause it. The technical contact maintains the code, deployment, and diagnosis. Name a backup who can act when either person is unavailable.
One person can fill several roles, but ownership needs time and authority. Agree who pays for maintenance and how urgent support requests reach someone. For agencies, make the client handover explicit: who controls hosting, repositories, subscriptions, and credentials, and what support continues after delivery?
NIST’s AI Risk Management Framework Core supports inventories, clear responsibilities, monitoring, and safe retirement for AI systems. Those are useful operating principles here too. However, code written with AI assistance does not necessarily use AI when it runs; assess what the finished tool actually does.
Write the operating note someone else will need
Keep the code and instructions in an organisation-controlled location. A repository link alone is not a handover. Write a short note covering:
- Purpose and people: users, owner, technical contact, backup, and consequences of failure.
- Running it: exact commands or job location, schedule and time zone, required software versions, configuration, and dependencies.
- Data and access: inputs, outputs, systems it reads or changes, and where authorised staff manage credentials. Never paste secret values into the note.
- Checks and recovery: expected results, alerts, safe stopping instructions, and the fallback process.
Then ask the backup to run it using those instructions and a safe test input. Any missing step they discover belongs in the note. If the tool calls an AI model during operation, also record the provider, model configuration, data sent, spending limits, and how output is checked.
Remove dependence on personal access
Check whether the tool stops working when its creator leaves. Where supported, use an organisation-managed application identity or service account with permissions limited to its task. Give administrators a documented way to recover access.
Follow OWASP’s secrets management guidance: keep credentials out of source files, use managed secret storage, restrict access, and document rotation and revocation. Keep secrets out of logs too. If a key has been exposed, revoke it and provision a replacement; deleting it from the latest file does not invalidate copies or repository history.
Check business results before trusting a successful run
A job can finish successfully and still produce the wrong answer. For a reconciliation script, check required columns, duplicate identifiers, record counts, and totals. Decide which failures should block publication and which need someone to review an exception.
Alert on missing scheduled runs as well as reported errors. Name the recipient and the next action: investigate, rerun safely, or tell users to use the fallback. A shared inbox is useful only if someone checks it.
Before releasing changes, test representative inputs and realistic failures, such as an empty export or renamed column. Store important code in version control and review changes before deployment. GitHub’s protected branch documentation explains how to require approving reviews and passing status checks; availability depends on the repository and plan. Choose a reviewer who understands the affected business rule or technical area.
Practise recovery, then review whether to keep it
Keep the previous working version and test the fallback where disruption would matter. Remember that reverting code does not undo records already changed. Document how to identify affected records, restore data where possible, and avoid duplicates when rerunning a partially completed job.
Set a review date based on the tool’s importance, and revisit ownership when staff, suppliers, or connected systems change. Retire tools that no longer earn their upkeep: notify users, preserve necessary records, stop schedules, and revoke unused access.
Start with one tool your team would struggle without. Greg can help map its dependencies, clarify responsibilities, and coordinate the practical fixes and handover. Talk with Greg about your internal tools.
Related on GrN.dk
- Search Console Can See Social Posts—Your Reports Need a New Map
- When Cloudflare Workers Become Shadow IT: A Practical Integration Register
- Drupal Deployments: Keep Small Fixes From Rewriting Live Settings
Need help with this kind of work?
Talk with Greg about your internal tools Get in touch with Greg.
