Maintenance & Takeover
Already have AI or automations in production, but nobody keeping them reliable and current? I take over existing systems, including those built by other providers.
The problem
AI systems and automations are often built quickly by an engaged employee, an external provider or a temporary project. Then circumstances change: the employee leaves, the provider is no longer available or the project budget ends. The system keeps running, but nobody fully understands it.
The risk grows gradually. Interfaces change, failures become more common, models and prompts become outdated, and the safeguards a production system needs are often missing: approval stages, logging and documentation. “It still more or less works” is not acceptable when real customer or business data is involved.
A rebuild may be unnecessary because the system still delivers value. What is missing is someone who can understand it, secure it and develop it responsibly.
The solution
I work through the existing system regardless of who built it and bring it to the standard required for dependable production use.
Existing AI systems and automations, including n8n and Make, are mapped systematically: what the system does, which access rights it uses, and where the failure points and risks lie. The result is often the system's first complete documentation.
Missing approvals, boundaries and logging are introduced using the KIKS approach: critical actions remain drafts or review items, permissions are defined and workflows are traceable. Data location is assessed where necessary.
The system is monitored and faults are analysed and corrected before they accumulate. Changes are controlled and documented rather than made silently.
Models, prompts and rules are improved and adapted as the underlying process changes. Support can also cover documented, project-specific GDPR and EU AI Act considerations for the live system.
Process
What is running, who built it and where are the problems? Initial assessment of condition and risk.
Workflows, access rights, failure points and missing safeguards are recorded systematically.
Prioritised measures identify what needs immediate attention and what can improve gradually.
Approvals, boundaries and logging are added, and unstable parts are stabilised.
The system is documented so that it can be operated independently of any one person.
Monitoring, troubleshooting and controlled development continue within the agreed scope.
Illustrative scenario
A company commissioned several n8n workflows from an external provider two years ago. Enquiries are pre-sorted, data is moved into spreadsheets and notifications are sent. The provider is no longer available. The workflows still run, but cases occasionally get stuck, nobody knows why and there is no documentation.
A typical takeover starts with an inventory: which workflows exist, what access they use and where failures occur. Critical steps without approval or logging are usually addressed first. Stuck cases are then analysed, the system is documented and the workflows move into monitored operations.
FAQ
Yes. That is common. The system inventory reconstructs what the system does and which access it uses. The time required depends on complexity, but the outcome is usable documentation, often for the first time.
I will explain the issue openly, including what can be secured at reasonable effort and where a rebuild would be the more honest recommendation. Unclear risks are not accepted into ongoing operations without assessment.
No. Support arrangements can be terminated under the Project Terms, and the documentation created during takeover makes you more independent. You can hand the system to your IT team or another provider.
Yes. Whether it was built internally or by a third party makes no fundamental difference. An internal solution may be sound and simply need safeguards, monitoring and consistent maintenance.
Responsibilities are documented before takeover: what I support, what remains with your organisation and how incidents are handled. AI results still require professional review, supported by technical approval stages rather than policy alone.
Next step
Briefly describe what is in use and where it is failing for a candid takeover assessment. You can also book a call directly.