AI Agents Writing to Maximo: The Governance Gap

Something quiet has changed in the way AI agents talk to Maximo. For most of the last two years the conversation has been about assistance: a chat panel that helps a technician find a manual, a generative summary of a long work log, a Collaborate session that recommends a probable failure code. The human still typed, clicked, and approved. The record in Maximo Manage was still written by a person. That assumption is now dissolving. AI agents in Maximo are increasingly being asked to take actions, not just make suggestions, and the governance model most estates run was not designed for a non-human actor.

This is an Analysis piece rather than a product review. The point is not that agentic patterns are good or bad. The point is that they change the identity of the writer on the record, and that change has consequences for change control, audit, integration architecture, and the operating model. Programme leaders and architects who leave those consequences to be discovered in production will find them the expensive way.

What has actually changed

Two things happened in parallel and are now converging on the same record.

IBM has been adding generative and agentic capability into MAS itself. Maximo Assist was renamed to Maximo Collaborate at the 9.1 release in June 2025, in part to disambiguate it from other IBM assistant products, and the surrounding platform work on MAS 9.x continues to add AI-led features into Manage. Vendor and community materials describe scenarios that go beyond retrieval and summarisation: intelligent work order creation, risk suggestions on work, recommended field actions. The direction of travel is clear even if any given operator has only turned on the read-only pieces.

At the same time, third-party agents are being wired into Maximo through its integration surface. The Integration Framework, the REST and OSLC APIs, and increasingly the Maximo automation stack are being used by external agent frameworks to fetch and mutate Maximo data. Publicly listed connectors already advertise coverage of work orders, assets, inventory and preventive maintenance across the major Manage functional areas. Whether the agent lives inside IBM’s estate or inside a customer’s own copilot programme, the practical effect on Maximo is the same: another actor is now able to write.

Most Maximo estates are not currently modelled that way. Their change control, their user auditing, and their integration governance all assume a bounded set of human users and a bounded set of named integration accounts doing predictable things.

Where the governance model bends

Three areas bend first.

The first is identity and attribution. Maximo has always kept a CHANGEBY on every meaningful record. That field is treated by auditors, by reliability analysts and by the safety function as the answer to the question “who did this?” When an agent creates a work order or closes a job plan step under a shared service account, that field becomes ambiguous. Two records with the same CHANGEBY may have been written by a person, by a scheduled integration, or by an agent acting on a natural-language request from a supervisor. The audit trail still exists, but the attribution has lost resolution at exactly the point regulators are starting to demand more of it.

The second is authorisation scope. Maximo security groups were built to model human roles: planner, storeperson, supervisor, reliability engineer. They are expressed as a set of applications, data restrictions, and conditional signatures. An agent that acts on behalf of a supervisor inherits, in practice, the union of what the supervisor can do and what the agent’s own service account can do. Very few estates have sat down and written the intersection they actually want. The result is that agents often end up with more effective privilege than the humans they are helping, because the shortest path to make a demo work is to grant the service account broad rights and rely on the calling application to behave.

The third is change control on the agent itself. A Maximo configuration change goes through a defined path: design authority, development, test, migration through Migration Manager or an equivalent, sign-off, production. That path assumes the thing being changed is a screen, a workflow, an escalation, or a script. An agent’s behaviour is defined by its prompt, its tool list, its retrieval sources, and its model version. All four of those can move without any Maximo configuration item changing. The estate can be certified against a design that no longer describes how work is actually being created.

What the standards bodies are already saying

The regulatory ground is shifting under this. The EU AI Act, in Article 14, requires that high-risk AI systems be designed to allow effective human oversight during use, including the ability for a natural person to intervene, override, or stop the system. A maintenance system that generates and closes safety-relevant work qualifies as high-risk in several plausible readings, particularly in energy, transport and water.

On the risk-management side, the NIST AI Risk Management Framework was extended in July 2024 with the Generative AI Profile (NIST AI 600-1), which identifies twelve categories of risk specific to or exacerbated by generative AI. Industry work on top of that framework, including the Cloud Security Alliance’s agentic profile, is explicit that autonomous and semi-autonomous agents that plan multi-step actions and invoke external tools sit outside the assumptions of the original RMF. The uncomfortable implication for asset owners is that the AI governance evidence pack they may have built for internal analytics does not automatically cover a Maximo-connected agent.

What a workable pattern looks like

The pattern that holds up in production is not a ban on agents. It is a set of design choices that put an agent into the estate as a first-class actor.

Give each agent a distinct identity. No shared “AI” account. Each agent has its own Maximo user, its own security group, and its own least-privilege scope. CHANGEBY then answers the audit question honestly.
Model the agent in the same way as any other integration. Its scope, its allowed object structures, its rate, and its failure behaviour go through the same integration governance as an ERP or historian link. If your estate uses the Integration Framework and REST APIs with reviewed contracts, an agent should not get a private door.
Treat model, prompt, tools, and retrieval as configuration items. They belong in the change register alongside application configurations and automation scripts. A change to any of them is a change to the system, whether or not Application Designer was opened.
Design the human-in-the-loop where the risk sits. For safety-relevant work, low-value automation is not worth the audit cost. Human approval on the write, with the agent’s rationale attached to the record, is a cleaner posture than trying to reconstruct the reasoning later.
Log the reasoning, not just the outcome. The value of an agentic action to an auditor is the trace: the prompt received, the tools called, the intermediate reasoning, the final Maximo transaction. Without it, the estate has an action with no defensible origin.

Operators who wire these choices into the design authority now, while the volume of agentic traffic is still low, will find the governance conversation manageable. Those who defer it until agents are already writing at scale will do the same work under regulatory pressure, with less freedom to design it well. Programmes that want a view of how this connects to the wider platform choices being made across the Maximo estate should look at how managed Maximo engagements are structuring the same controls today.

AI Agents Writing to Maximo: The Governance Gap

What has actually changed

Where the governance model bends

What the standards bodies are already saying

What a workable pattern looks like

Sources