Keep an accepted AI system observable, recoverable and ready for change
Maintenance Agreement (MA) is a scoped operating service after handover. We agree what is monitored, who approves access and changes, how incidents are handled, and what evidence is reviewed — without treating maintenance as a model accuracy warranty.
What MA covers
The final scope depends on the system inventory, support window, site and contract. These are the workstreams to confirm during an MA assessment.
System operations
Health checks for service, container, runtime, device, storage, compute, temperature, network, queues and integrations.
Inventory, health signal and incident record
Model operations
Versioning, release notes, drift signals and retraining triggers when data, labels and acceptance criteria exist.
Model change note and evaluation result
Security and continuity
Patch and dependency review, configuration backup, restore or rollback checks, and a recovery path agreed to the architecture.
Approval, backup/restore check and recovery note
Customer enablement
Runbook, escalation matrix, review cadence and training for the named customer owner and decision maker.
Health report, decisions and improvement backlog
The MA operating lifecycle
- 01
Baseline
Record versions, devices, model, metrics, dependencies and ownership before support starts.
System inventory and baseline report
- 02
Monitor
Watch agreed health, latency, queue, storage, integration and drift signals within the data boundary.
Dashboard/alert and incident record
- 03
Review
Review monthly or quarterly with the system owner; separate measured facts from open assumptions.
Health report and risk list
- 04
Change
Patch, tune or update only through an approved change request with a test and rollback plan.
Release note, test result and approval
- 05
Recover
Use the agreed backup, rollback or spare-device path when an incident requires it.
Recovery evidence and post-incident note
- 06
Improve
Prioritise the next safe improvement from evidence, operator feedback and an accountable owner.
Backlog and target review date
Managed AI Operations is an optional scope
Managed AI Operations can add monitoring, review coordination and operational reporting when the team, access model and agreement support it. It is not implied by having an MA, and it does not transfer business decisions or model accountability to us.
- Monitoring and alert triage within the agreed boundary
- Recurring health review and risk/backlog facilitation
- Release, dependency and compatibility coordination
- Incident communications and recovery exercise support
Data boundary and remote access
The default is to keep business payload inside the customer environment. The exact telemetry and access path are confirmed in the architecture and contract.
| Surface | Default handling | Approval / evidence |
|---|---|---|
| Business payload | Images, documents, prompts and workflow payload stay on the customer network unless an explicit contract says otherwise. | Architecture decision and customer data owner approval |
| Health telemetry | Only agreed health metrics may leave the site; monitoring can remain inside the customer environment. | Allow-list, retention and monthly review |
| Remote support session | No standing access. Each session has an approver, purpose, expiry and least-privilege path. | Access approval and audit log |
| Backup and logs | Location, retention, encryption and restore path follow the customer architecture and contract. | Restore check and handover inventory |
| Model training | MA does not grant permission to train CerebraTech AI models on customer data. | Separate written agreement if any data use is proposed |
Example support structure — confirm values in the agreement
This is a template for a scope workshop, not a guaranteed package. Response means acknowledgement and triage; restore and final resolution depend on customer access, hardware, data and third parties.
| Severity | Example | Response target | Restore / resolution |
|---|---|---|---|
| S1 | Production workflow stopped or safety-critical integration unavailable | To be agreed | RTO/RPO or architecture exception to be agreed |
| S2 | Material degradation with a workaround available | To be agreed | Target and update cadence to be agreed |
| S3 | Limited function, report issue or non-urgent defect | To be agreed | Planned change or next review |
| S4 | Question, request or improvement backlog item | To be agreed | Scoped change request if approved |
- Service window
- Business hours, extended hours or 24×7 — contract value required
- Timezone
- Asia/Bangkok (ICT), unless the agreement specifies another clock
- Channels
- Ticket first; phone, chat or on-site only when included in scope
- Customer dependencies
- Named owner, access approver, network, spare/device plan, data labels and third-party support
Sample monthly AI health report
Template only — the following is a report structure, not a customer result or benchmark.
Executive summary
Green / Amber / Red status, notable changes and decisions needed
System health
Availability, latency, queue/failure, storage and resource signals that were actually measured
Model and data signals
Drift proxy, human review and evaluation context when labels and method exist
Incidents and changes
Response, restore, root-cause notes, patches, approvals and rollback readiness
Risk and next steps
Customer decisions, owner, due date and improvement backlog
Handover and offboarding are part of the service
The agreement records what each side owns. At handover or exit, access and artefacts are returned or revoked according to the contract; this is not a promise of zero lock-in.
| Area | Customer owner | Service responsibility | Handover / exit evidence |
|---|---|---|---|
| Business data and decisions | Data owner and operational approver | Process only within the agreed boundary | Data map and decision record |
| Code, model and configuration | Accept versions and change decisions | Maintain only listed components and dependencies | Version inventory and release notes |
| Access and operations | Approve sessions and provide site dependencies | Use least privilege and keep an audit trail | Access log, revocation and runbook |
| MA closure | Confirm acceptance and receiving owner | Deliver agreed inventory/log export and remove our access | Offboarding checklist and outstanding-risk note |
What MA does not promise
- Model accuracy without a dataset, method and acceptance criteria
- New features, retraining or hardware changes without a scoped change request
- Network or third-party cloud service responsibility unless the contract names it
- A hardware warranty, zero downtime or zero lock-in
- Permission to use customer payload for CerebraTech AI model training
Start with a support-scope workshop
Tell us what is already in production, what can stop, what evidence exists and who can approve access. The next step is an MA assessment or support-scope workshop — not an automatic quote.
Request an MA assessment