Maximo AI Service: Operationalizing the Maximo Assistant in MAS 9.1

The arrival of Maximo AI Service in MAS 9.1 marks a turning point for how work gets done inside Maximo Manage. For two decades, Maximo users have navigated hierarchical menus, built queries, and learned the MBO framework to extract value from the system. The Maximo Assistant replaces that with a conversational interface that lets a planner type "show me the open priority 1 work orders for Pump 14-B at the Houston site" and get a real answer in seconds. Behind the assistant is a broader AI Service that also drives problem code recommendations, similar work order detection, field value recommendations, and AI-augmented FMEA content.

But turning on Maximo AI Service is not a checkbox exercise. It requires deploying the service alongside Manage, configuring model templates, training models on your data, and integrating with IBM watsonx.ai for inferencing. This article walks through the architecture, the operational setup, the model training workflow, and the patterns that distinguish a successful Maximo AI deployment from one that stalls at the proof-of-concept stage.

From AI Broker to Maximo AI Service

The predecessor to Maximo AI Service was the AI broker, an add-on introduced in earlier MAS releases. As of August 1, 2025, the AI broker is end-of-life. Organizations still running the broker must uninstall it (along with its MariaDB dependency) and deploy Maximo AI Service 9.1 to retain AI features. The service is supported on both MAS 9.0 and MAS 9.1, but the full feature set is only available with MAS 9.1.

Maximo AI Service 9.1 is a separately deployable component that runs in the same OpenShift cluster as Maximo Manage. It uses the Maximo AI Service to manage model configuration, training, retraining, and data retention. Inferencing is delegated either to a watsonx.ai instance or to a local embedded runtime, depending on the deployment model. Health checks for both the runtime and individual models are handled inside the service.

The licensing model is AppPoint-based, but with an important caveat. Maximo AI Service 9.1 includes a limited-use license to watsonx.ai, but only when both the service and the watsonx instance are deployed in the same model (both on-premises, or both SaaS). If you deploy Maximo AI Service on-premises and use SaaS watsonx.ai, the watsonx side cannot use AppPoints; you must procure and pay for watsonx separately. Plan this carefully if you have a hybrid architecture.

A second caveat is language. The current model templates and training pipelines support English only. Data that is not in English cannot be used to train models or generate inferences. If you operate globally, evaluate the impact on your data set before deployment. This is documented in IBM's Maximo AI Service documentation and was discussed actively in the community around the 9.1 launch.

The AI Feature Catalog

Maximo AI Service 9.1 enables five core AI features in Maximo Manage. Each feature has a model template, a base model, and a configuration step.

Problem code recommendations for work orders uses the pcc model template with the gpt-oss-120b model. As a technician enters the description and failure details of a work order, the model recommends the most likely problem code from your classification hierarchy. Training data is drawn from historical work orders, so the recommendations are calibrated to your failure patterns, not generic. In deployments where the recommendation acceptance rate is above 70 percent, time to enter a work order drops by an average of 90 seconds per record, and the consistency of problem code usage improves measurably.

Field value recommendations uses the mcc model template with the same base model. It recommends values for fields such as failure cause, remedy, and component based on the context of the work order. This is the most powerful feature for new technicians, because it shortens the learning curve for entering consistent data. The field value recommendation feature typically delivers the highest ROI in deployments where there is high technician turnover or a large contingent workforce.

The AI Assistant uses the nl2oslc model template. This is the conversational interface that translates natural language questions into Maximo queries. It can return lists, counts, sums, averages, and drill-down detail. It is embedded in the Maximo UI and uses Maximo's existing security context, so users only see data they are authorized to see. The assistant supports natural language aggregations that previously required a BIRT report or a saved query, making it a force multiplier for planners and supervisors who need quick answers.

Locating similar work orders uses the similarity model template, which is built on an embedding model called embedding_transformer_en_slate.125m from Watson Natural Language Processing. When a technician opens a work order, the AI surfaces the three to five most similar historical work orders based on description, failure codes, and asset context. This accelerates resolution by leveraging institutional knowledge that would otherwise be trapped in the heads of senior technicians. Embedding models work by converting text into high-dimensional vectors, then computing similarity as the cosine distance between vectors.

AI recommendations for asset boundary and failure list in Reliability Strategies uses the fmea model template. It helps reliability engineers build FMEAs by suggesting asset boundary limits and a starter failure mode list, which the engineer then refines. FMEA construction is one of the most labor-intensive activities in reliability engineering, and AI assistance reduces the time to produce a draft FMEA by 40 to 60 percent in early deployments.

A sixth feature, AI insights into asset condition, is currently available in the feature channel. It uses the insightsgenerator template and gives planners a natural-language summary of an asset's recent work history, condition, and risk indicators. Customer-managed users can preview it in non-production instances; SaaS customers can enable it in their production environment.

Deploying Maximo AI Service: The Step-by-Step

Deployment follows a defined sequence. Step one is to remove the legacy AI broker if it is installed. The broker, its MariaDB database, and any associated persistent volumes must be cleaned up before installing the new service. Step two is to install Maximo AI Service 9.1 from the IBM Automation Catalog in the OpenShift container platform. The service is installed as a separate operator and creates its own custom resources.

Step three is to configure the integration with watsonx.ai. This involves creating an API key in your watsonx instance, storing it in an OpenShift secret, and pointing the AI Service custom resource at the watsonx endpoint. If you are using an on-premises watsonx deployment, the endpoint is the URL of your watsonx cluster. If you are using SaaS, the endpoint is the IBM Cloud watsonx URL for your region.

Step four is to create the AI configurations that map model templates to enabled features. Each feature has a separate configuration object that specifies the model template, the training data source, and the inferencing behavior. A typical configuration might look like this:

apiVersion: ai.maximo.ibm.com/v1
kind: AIConfig
metadata:
  name: problem-code-recommendations
  namespace: mas-ai
spec:
  feature: pcc
  modelTemplate: gpt-oss-120b
  training:
    source: maximo.workorder.history
    minRecords: 5000
    retrainSchedule: "0 2 * * 0"
  inference:
    batchSize: 16
    maxRecommendations: 5
    confidenceThreshold: 0.65
  scope:
    sites:
      - HOUSTON
      - BATONROUGE
    classifications:
      - PUMP
      - COMPRESSOR

This configuration enables the problem code recommendation feature for two sites and two asset classifications, trains on the historical work order data, and retrains weekly on Sunday at 2 AM. The confidence threshold filters out low-quality recommendations so that technicians are not overwhelmed with noise.

Model Training: Compute, Time, and Data

Model training is the operationally expensive part of Maximo AI Service. Training a problem code recommendation model on a data set of 50,000 work orders with a gpt-oss-120b model template can take between 4 and 12 hours depending on the OpenShift worker node sizing and the complexity of your classification hierarchy. Field value recommendations typically train faster because the data set is smaller. The assistant and similarity models train fastest because they operate on a more focused slice of the data.

Plan compute capacity accordingly. Training consumes significant CPU and memory. Most teams provision a dedicated worker node pool for AI training with 4 to 8 CPU and 16 to 32 GB of memory per node, and they schedule training during off-peak hours. The inferencing path is much lighter, but it still requires a small footprint. The AI Service runs an embedded runtime for some models, which means inference happens inside the same cluster rather than round-tripping to watsonx.

The data quality of the training set determines the quality of the recommendations. If your historical work orders have inconsistent problem codes, free-text descriptions that mean the same thing are coded differently, or failure codes are rarely used, the model will learn those inconsistencies. Before training, run a data quality report. Identify the top 20 percent of work orders that account for 80 percent of the volume. Clean those first. The long tail is less impactful and can be addressed in subsequent training cycles.

A useful pattern is to start with one site, one classification, and one feature. Train the model. Deploy it. Measure the recommendation acceptance rate (how often does the technician accept the AI suggestion). If the acceptance rate is above 60 percent, expand to additional sites and classifications. If it is below 40 percent, the data is not yet ready, and you need to invest in data quality before scaling.

Automation Script Compatibility in the AI Era

Maximo AI Service does not replace automation scripts; it complements them. But the introduction of AI-generated field values and problem codes does change how some scripts need to behave. Scripts that fire on attribute change events need to be aware that the value may have been set by an AI recommendation. If your script overrides AI-set values, you will get unpredictable behavior.

A common pattern is to add a check at the start of an attribute launch point script that determines whether the change is user-driven or AI-driven. The Maximo AI Service tags AI-set values with a marker that can be detected in the script. A Jython automation script that respects AI recommendations might look like this:

if mbo.getBoolean("ISAIRECOMMENDED"):
    service.log_info("Skipping override on AI-recommended value")
    return
else:
    # existing override logic
    mbo.setValue("PRIORITY", recalculatePriority(mbo))

This pattern prevents the script from clobbering AI recommendations while still applying custom logic to user-entered values. It is especially important for problem code and failure code launch points, where the AI is most likely to be the source of the value.

Another compatibility concern is the bean-class bridge. The mxe.script.allowBeanScript system property enables scripts to invoke compiled Java classes. The AI Service does not require this property, but if your existing scripts depend on it, the same restriction applies. The property is off by default for a reason, and it should be enabled per-environment rather than globally. Audit which scripts use the bridge, document them, and review them for Java 17 compatibility.

Common Pitfalls When Enabling AI

The first pitfall is treating AI as a replacement for data quality. If your problem codes are inconsistent, AI will produce inconsistent recommendations. The technology amplifies the patterns in your data, good and bad. Invest in data quality first.

The second pitfall is over-deploying. Enabling all five AI features across all sites on day one creates more problems than it solves. Different features have different training data requirements, different retraining cadences, and different user training needs. Start with one feature, one site, one user group. Measure. Expand.

The third pitfall is ignoring the inferencing cost. Each AI recommendation consumes AppPoints and (in many cases) watsonx.ai capacity units. A configuration that returns five recommendations on every work order save for 5,000 work orders per day is 25,000 inference calls per day. At a few seconds per call, that is meaningful compute. Tune the confidence threshold and the number of recommendations to balance usefulness and cost.

The fourth pitfall is skipping user training. The Maximo Assistant is intuitive for power users, but a planner who has never used a natural language query interface may not know what to ask. Build a library of example questions. Run a 30-minute training session for each user group. Publish a cheat sheet. Adoption is the most common reason AI initiatives fail, and adoption is driven by user enablement.

Practical Implications

For administrators, Maximo AI Service means a new set of operational responsibilities. You are now responsible for training data quality, model retraining schedules, inference cost monitoring, and the AI configuration custom resources. Budget for a part-time AI administrator role, or fold the responsibility into an existing Maximo administrator who has the bandwidth and interest.

For application managers, the AI Service means new KPIs. The recommendation acceptance rate is the most direct measure of value. The time to enter a work order is a leading indicator. The accuracy of AI-generated problem codes, measured against eventual root cause, is a lagging indicator. Track these monthly and use them to drive retraining decisions.

For data teams, the AI Service creates a new feedback loop. When a technician rejects an AI recommendation, that data point is captured. When they accept and modify it, the modified value can be used to retrain. The retraining pipeline should consume this feedback data automatically. The model improves over time as long as the feedback loop is closed.

For security teams, Maximo AI Service introduces new data flow considerations. Work order data is sent to the model for inference. If the model is in watsonx.ai (whether SaaS or on-premises), the data crosses a trust boundary. The data is encrypted in transit, but the inference logs may persist in watsonx. Review your data retention policies for AI inference logs and ensure they align with your regulatory requirements.

Bottom Line

Maximo AI Service is the most significant functional addition to Maximo Manage in years. The Maximo Assistant alone changes how users interact with the system. The problem code and field value recommendations improve data quality and accelerate work order entry. The similar work order feature surfaces institutional knowledge. The FMEA assistance accelerates reliability engineering. None of these features require rip-and-replace; they layer onto your existing Maximo deployment.

The operational path is clear. Remove the legacy AI broker. Deploy Maximo AI Service 9.1. Configure watsonx.ai integration. Create AI configurations for the features you want to enable. Train on historical data. Deploy to a pilot site. Measure acceptance rates. Refine data quality. Expand gradually. The pattern that works in the field is conservative rollout with tight feedback loops.

The AppPoint cost is real but bounded. The licensing model is consumption-based, so you pay for what you use. The model templates and base models are provided. Your investment is in data quality, model training infrastructure, and user adoption. If you invest in those three areas, the AI Service delivers measurable value within the first quarter of deployment.

For organizations still on Maximo 7.6.x, the AI Service is one more reason to plan the MAS 9.1 migration. For organizations already on MAS, the question is not whether to enable Maximo AI Service, but when and how. Start the deployment planning now. The capability is mature, the documentation is solid, and the value is tangible.