Governance, Data Privacy & AppPoints: The Decisions You Make Before You Turn On the Assistant
🎯 Who this is for: Program leaders, security and compliance stakeholders, and licensing owners who need to answer the hard questions about generative AI in Maximo — where the data goes, who can use it, and what keeps it in line — before the first user ever types a natural-language query.
Series: Part 6 of 6 — Maximo Assistant on MAS 9 | Read time: 17 minutes | Series Finale
AI Is a Governance Conversation First
Five parts of this series have been about capability — what the Assistant does, how it drafts and recommends and guides, how you deploy it. This finale is about the questions that determine whether you should turn it on, and how to do so responsibly: where does our data go, who gets access, and what keeps the AI from going off the rails?
Here is the reassuring news up front: MAS 9 makes these questions answerable, and the controls you need are largely already in the design. You are not bolting governance onto an ungoverned system. You are making a handful of deliberate decisions — data residency, human-in-the-loop, access, feedback — that MAS gives you the levers to make. This post walks each one and ends with a go-live checklist.
🌍 Data Residency Is a Deployment Decision
The single most consequential governance decision is one you meet on day one of deployment, and it is easy to treat as a purely technical fork: do you run watsonx.ai as SaaS or on-premises?
IBM's team-exploration tasks put this decision first for a reason. Task AI-1 is "evaluate watsonx.ai deployment options (SaaS vs on-premises)" — before you deploy the operator, before you connect anything. It leads the list because it governs where your maintenance data is processed by the AI.
| Option | What it means for your data |
|---|---|
| watsonx.ai SaaS | Model training and inference use IBM's cloud; faster to provision, less to operate |
| watsonx.ai on-premises | Training and inference stay inside your environment; you control residency, more to operate |
For many organizations, this is a straightforward choice. For those in regulated industries, jurisdictions with data-residency laws, or environments with strict data-handling policies, it is the decision — the one that determines whether AI Assist is even permissible. An on-premises watsonx.ai keeps your work-order history, asset data, and repair narratives within your boundary; SaaS trades some of that control for speed and lower operational burden.
<aside>
💡 Key insight: Do not let AI-1 default. If nobody explicitly decides SaaS-versus-on-premises, the deployment team will pick whatever is easiest to stand up — and that may not be what your compliance posture requires. Bring security and compliance into AI-1 before watsonx.ai is provisioned. Reversing this decision after go-live means re-provisioning the AI foundation, which is far more expensive than getting it right the first time.
</aside>
The broader point: because the Assistant is trained on and retrieves from your data — work orders, failure narratives, asset records — the question "where does that data get processed" is not abstract. It is the crux of AI data privacy for Maximo, and MAS gives you a real answer in the deployment model rather than leaving you to trust a black box.
🎛️ Your Governance Controls Are Built In
The second reassuring fact: the controls that keep the AI a recommender rather than a decider are not features you have to add. They are in the design, and they showed up throughout this series. Your governance job is less "build controls" and more "make sure people use the controls that exist."
Three built-in controls carry the load:
| Control | What it governs | Where it appeared |
|---|---|---|
| Confidence scores | How much to trust each recommendation | Part 2 (field recommendations) |
| Accept / modify / reject | Every AI action ends with a human decision | Parts 2 and 4 |
| Feedback loop | AI behavior is shaped by governed human feedback | Parts 1 and 5 |
Together these enforce the theme that has run through the whole series: the Assistant recommends; humans decide. The work order draft ends with "would you like me to submit it?" The field recommendation carries a confidence score and waits for accept, modify, or reject. The PM optimization surfaces a suggestion for a reliability engineer to judge. There is no documented mode in which the AI silently commits a change to your system of record.
<aside>
💡 Key insight: The biggest governance risk with these controls is not that they are missing — it is that users click past them. A team that reflexively accepts every recommendation to save two seconds has effectively disabled the human-in-the-loop control while leaving it technically present. Governance here is behavioral: train people to read the confidence score, to correct wrong recommendations, and to treat the accept/reject choice as a real decision. The control is only as strong as the attention behind it.
</aside>
This is why data-privacy and AI-safety governance for the Assistant is less about restraining a powerful autonomous system and more about sustaining human engagement with a helpful one. The architecture keeps the human in the loop; your policies and training keep the human awake in the loop.
🔁 The Feedback Loop Needs Governance, Not Just Enablement
Part 5 framed the feedback loop as the engine of long-term value. From a governance seat, it needs a second look — because "capture user acceptance/rejection of recommendations for retraining" is a data process, and data processes deserve oversight.
Think about what the feedback loop actually does: it observes your users' decisions and uses them to reshape the model. That is powerful and beneficial, and it also means the model's future behavior is being determined by a stream of human choices you should be able to see and steer. Governance questions worth answering:
- Who owns the retraining cycle? IBM's task AI-10 is "plan the retraining cycle and feedback-loop process." Someone must own it, or the loop runs unsupervised or not at all.
- Is the feedback representative? If only one shift or one site provides most of the accept/reject signal, the model drifts toward their patterns. Governance means noticing that.
- Are corrections being made in good faith? A culture of blind acceptance (see above) poisons the training signal. Monitoring recommendation accuracy over time (task AI-9) is how you catch a loop that is learning noise.
<aside>
💡 Key insight: Treat the feedback loop like any other data pipeline that influences decisions: give it an owner, monitor its inputs, and review its outputs. An ungoverned feedback loop does not fail loudly — it quietly makes the model reflect whatever behavior your users happen to exhibit, good or bad. The loop is an asset when governed and a slow-acting liability when ignored.
</aside>
💳 AppPoints: Who Gets the AI
The third governance lever is licensing — and in MAS, licensing is access control. The Assistant is gated by AppPoints, the shared MAS licensing currency.
The model is a pool, not a per-app purchase. You buy a pool of AppPoints and allocate them across any combination of MAS applications; points can be reallocated within your contract terms. Here is where AI Assist sits:
| Application | AppPoints per user (typical) | License type | Notes |
|---|---|---|---|
| Manage — Base | 10 | Authorized | Standard EAM |
| Manage — Premium | 15 | Authorized | Full functionality including add-ons |
| AI Assist | Varies | Authorized | Included with Premium in some contracts |
| Mobile | Included | N/A | Included with Manage license |
Two governance-relevant facts jump out. First, AI Assist is licensed per authorized user — so who has AI-enabled access is a deliberate allocation you control, not a blanket switch. Second, in some contracts AI Assist is included with Manage Premium — meaning your organization may already be paying for AI capability it has never turned on. Before you budget a new line item, check whether your Premium contract already grants it.
Because access is allocation, you can gate the AI to the roles that benefit most. IBM's role-based allocation strategy is a sensible template:
| Role | Applications | AppPoints/User |
|---|---|---|
| Maintenance Manager | Manage Premium + Health + Predict | 30 |
| Reliability Engineer | Manage Base + Health + Predict + Monitor | 30 |
| Planner/Scheduler | Manage Base + Optimizer | 20 |
| Technician | Manage Base + Mobile | 10 |
| Executive | Manage Limited + Health (dashboards) | 10 |
<aside>
💡 Key insight: AppPoints allocation is a quiet but real AI-governance control. By deciding which roles get AI-enabled (Premium) access, you simultaneously manage cost and scope who can use generative features on your data. Start narrow — give AI-enabled access to the power users and roles with the strongest data and the clearest benefit — prove value, then expand. And always confirm exact AI Assist costs with your IBM representative, since they vary by contract and change over time.
</aside>
Base vs Premium, authorized vs concurrent
Two distinctions inside the AppPoints model change the math, and both are worth understanding before you sign an allocation. The first is Base versus Premium:
| Category | Base AppPoints | Premium AppPoints |
|---|---|---|
| Manage access | Standard EAM | Full EAM plus add-ons (Spatial, Transportation, Aviation, and so on) |
| AI features | Basic | Full AI Assist, advanced recommendations |
| Integration | Standard APIs | Advanced connectors |
| Cost | Lower per point | Higher per point |
That middle row is the one that matters for this series: the richer AI Assist experience sits on the Premium tier. If your allocation is entirely Base, do not be surprised when the advanced recommendation features you read about in Parts 2 and 4 are thinner than expected. Deciding who needs Premium is, in practice, deciding who gets the full Assistant.
The second distinction is authorized versus concurrent licensing. An authorized user is anyone with access; a concurrent license counts only users active at the same time. If a role is used by many people but only a fraction are ever logged in at once — think seasonal inspectors or a large but part-time requestor base — concurrent licensing can be materially cheaper. And because AppPoints are a flexible pool you can reallocate within your contract terms, an allocation is a decision you revisit, not a one-way door.
Choosing an allocation strategy
IBM outlines three allocation patterns, and the right one depends on where you are in the rollout:
| Strategy | How it works | Best when |
|---|---|---|
| Start narrow, expand later | Put most points on Manage first; reallocate to add-ons as you deploy Health, Predict, and AI Assist | You are running a phased implementation and want to prove each capability before funding it |
| Power-user model | A small group gets access to everything (high points per user); everyone else gets Manage-only | You are still exploring the suite and want a few people fluent across it |
| Role-based allocation | Points mapped deliberately to roles (the table above) | You know your personas and want cost to track benefit precisely |
For AI Assist specifically, "start narrow" and "role-based" tend to combine well: give AI-enabled access to the reliability engineers, planners, and maintenance managers whose work most benefits and whose data is richest, prove the accuracy on that slice (the AI-9 gate from Part 5), then widen.
Keeping the pool honest
Allocation is not a one-time act. IBM's guidance on optimizing AppPoints usage is really a set of ongoing governance habits:
- Audit actual usage. Not every licensed user actively uses every application. MAS provides usage reports — read them, and reclaim points from access nobody exercises.
- Use Limited licenses where the work is view-only. Many users only need to see records, not transact on them; a Limited seat costs far fewer points than a Base one.
- Do not allocate to what you have not deployed. Points parked on an application you have not stood up are pure waste.
- Right-size Premium against Base. Premium only where the AI features and add-ons justify the higher per-point cost; otherwise Base.
- Revisit after every phase. Because the pool flexes, each deployment milestone is a chance to rebalance toward where the value actually landed.
<aside>
💡 Key insight: The governance failure here is silent over-allocation — Premium seats and AI-enabled access handed to users who never touch the features, quietly burning points that could fund a Predict pilot or a Monitor rollout. An annual (or per-phase) AppPoints audit is as much a part of AI governance as the data-residency decision. Under-used entitlement is not neutral; it is budget your program could be spending on capability people would actually use.
</aside>
🧭 A Worked Governance Decision
Abstract principles get real when you walk one organization through the six decisions. Consider a regional water utility standing up AI Assist — a useful case because water utilities carry both regulated inspections and genuine data-residency sensitivity.
- Data residency (AI-1). The utility's compliance office flags that customer and infrastructure data cannot leave its jurisdiction under its regulator's data-handling rules. That single constraint decides AI-1: on-premises watsonx.ai, accepting the extra operational burden to keep training and inference inside the boundary. Notice the decision was driven by compliance, not by the platform team's convenience — exactly as it should be.
- Access allocation. They already hold Manage Premium for a subset of staff. Checking the contract (the step everyone skips) reveals AI Assist is included with Premium for those seats — so the pilot needs no new licensing line item. They scope AI-enabled access to eight reliability engineers and planners, the roles with the richest failure-coded history.
- Human-in-the-loop policy. Because several of their PMs are legally-mandated inspections, they write an explicit rule: PM optimization recommendations on regulated inspections are advisory only and are reviewed by a named reliability engineer — the AI never removes a compliance-critical task (the Part 4 boundary made into policy).
- Feedback-loop owner (AI-10). One reliability engineer is named owner of the retraining cycle, responsible for watching that the accept/reject signal is not dominated by a single shift and that accuracy holds over time.
- Accuracy gate (AI-9). They set a go/no-go: field recommendations must be accepted by users more than 60% of the time on their own assets before access widens beyond the pilot eight.
- Safety guardrail documented. In writing: no AI recommendation auto-closes a work order or auto-removes an inspection; every safety- or compliance-critical action ends with a named human.
The point of the walkthrough is that none of these was a technology decision. Each was a policy choice that MAS gave them the levers to make — and each was decided before the first natural-language query was ever typed.
🩺 Governance Failure Modes to Watch For
Governance rarely fails loudly. It fails quietly, in patterns worth naming so you can catch them early:
| Failure mode | What it looks like | The fix |
|---|---|---|
| Defaulted residency | Deployment team picked SaaS because it was fastest; compliance was never consulted | Make AI-1 a signed-off decision with security in the room, before provisioning |
| Rubber-stamp culture | Users accept every recommendation to save two seconds | Train the confidence-score bands; reward correction, not just speed; monitor accept rates |
| Ungoverned feedback loop | No owner; model drifts toward one shift's habits | Name the AI-10 owner; check that feedback is representative |
| Silent over-allocation | Premium seats and AI access on users who never use them | Run the AppPoints audit; reclaim and reallocate |
| Safety-critical erosion | A PM optimization quietly trims a regulated inspection | Written rule that compliance-critical items are advisory-only, human-reviewed |
| Accuracy assumed, never measured | Rolled out wide without checking recommendations on real assets | Enforce the AI-9 go/no-go gate before widening |
The through-line: every one of these is a behavioral or process failure, not a technology failure. MAS gives you the controls. Governance is the discipline of making sure they are actually used.
✅ A Go-Live Governance Checklist
Pull it together into the decisions to make before the first user logs in:
- [ ] Data residency decided (AI-1). SaaS vs on-premises watsonx.ai chosen with security and compliance in the room, not defaulted by the deployment team.
- [ ] Human-in-the-loop policy written. Explicit expectation that users read confidence scores and treat accept/modify/reject as a real decision, with training to match.
- [ ] Feedback-loop owner named (AI-10). A person accountable for the retraining cycle, monitoring representativeness and accuracy over time.
- [ ] Access allocation set. AppPoints allocated by role so AI-enabled access maps to who benefits; Premium contract checked for included AI Assist.
- [ ] Safety-critical guardrails documented. Clear rules that AI recommendations never auto-remove safety- or compliance-critical items (e.g., PM optimization on regulated inspections — Part 4).
- [ ] Accuracy assessed on your data (AI-9). A go/no-go gate confirming recommendations are trustworthy on your assets before wide rollout.
If those six are decided, you are turning on the Assistant responsibly — not just technically.
Key Takeaways
- The SaaS vs on-premises watsonx.ai choice (IBM's task AI-1) is fundamentally a data-residency decision — make it deliberately, with compliance involved, before provisioning.
- Your primary governance controls are built in: confidence scores and the accept/modify/reject step keep the AI a recommender, never a decider — governance is behavioral, ensuring people actually use them.
- The feedback loop is a governed data process, not just a feature — give it an owner (AI-10), monitor representativeness, and watch accuracy over time (AI-9).
- AppPoints license AI Assist per authorized user; it may already be included with Manage Premium, so check before budgeting, and use role-based allocation to gate access and cost.
- Governance decisions belong before go-live — the six-item checklist (residency, human-in-the-loop, feedback owner, access, safety guardrails, accuracy gate) is the responsible way to turn it on.
Series Complete
You have reached the end of Maximo Assistant on MAS 9. You now have the full picture: the watsonx foundation (Part 1), natural-language work guidance (Part 2), SME collaboration and knowledge capture (Part 3), guided troubleshooting (Part 4), the deployment path (Part 5), and the governance that frames all of it (Part 6). The Assistant is real, it is useful, and it is bounded — an assistant, not an agent, trained on your data, governed by your choices.
References
- IBM Maximo Application Suite Documentation
- AppPoints Licensing (IBM Documentation)
- IBM watsonx.ai Documentation
- Maximo AI Service (IBM Documentation)
Series Navigation
| Previous: | Part 5 — Configuration & Deployment |
|---|---|
| Next: | You have completed the series |
About TheMaximoGuys: We help Maximo developers and teams navigate the move to MAS 9 with practical, no-hype guidance grounded in how the platform actually behaves.
Published by TheMaximoGuys | July 2026
Venkat Achanta
