In pilot use, Toyota Motor North America's SAP engineers supervised the runbook instead of running it

SAP maintenance leaves no room for improvising. Application servers drain before central services stop, shared databases must not be stopped while the applications that depend on them are still running, and everything comes back up in a set order. Engineers on Toyota Motor North America's SAP team used to work through that runbook while moving between terminals, SAP GUIs, spreadsheets and AWS consoles.

During the pilot, that job changed. In an AWS blog post published October 28, 2026 and co-authored with the team, Toyota describes BasisPilot, an in-house operations platform with an AI assistant built in. It covers "20 SAP systems on 60+ Amazon EC2 hosts across development, test, stage, and production environments." The key line: "During pilot use, the engineer's role shifted from executing a manual runbook to supervising an approved workflow."

The risk with automation is rarely that the tool is too weak. It is switching it on before anyone has built a way to stop it. Toyota's team built the stop first. Viewer roles stay read-only. "Production actions, multi-tenant database hosts, and destructive operations always create a pending approval instead of executing." Before a kernel upgrade, the assistant shows a pre-check with Proceed and Cancel buttons, and at that point "no change has been made." If startup verification fails, the workflow restores the backed-up kernel. "Generated text never becomes a shell command." In the kernel upgrade, the engineer no longer carries out every step. The engineer decides whether the steps run at all.

That order was deliberate. "I started with the decisions a Basis engineer has to make before touching a system: what evidence do I trust, what has to happen in what order, and what should stop me," says Manish Kumar, a senior SAP product owner on the team.

The results so far are the team's estimates from the pilot. Across 15+ kernel upgrades in May 2026, the work went from about 2.5 hours to 45 minutes of elapsed time per system, "a reduction of about 70%." Across 30+ filesystem reductions in March 2026, elapsed time came to approximately one hour, compared with three to four hours before, about 67 to 75% less. The team also estimates "at least 20% less time spent gathering and analyzing operational information," and reports "an estimated 25% reduction in status-related tickets" after other teams were given self-service visibility.

The write-up also records the time the automation tripped over itself. In early testing, a stalled stop-tracker's retry fired minutes after a successful AI-assisted upgrade had restarted the system, creating a conflicting stop action. The team added workflow locks per system and freshness windows on retries and approvals. A retry, the post says, "must re-check state before acting."