Three Layers of AI on a PMIS

Most organisations evaluating AI for their project systems are looking at one third of the picture, and it is the third they control least.

The evaluation usually runs like this. The vendor presents a roadmap. The team assesses the features against a requirements list. Someone asks about timing. A score is assigned. The exercise is entirely reasonable and it is also incomplete, because the vendor's feature list is only one of three places AI value on a PMIS comes from.

Understanding all three changes the question you are asking. It moves from what AI does your product have to what AI can I run on my project data, and organisations asking the second question end up in a materially better position than those asking the first.

Most PMIS AI evaluation stops at the vendor's feature list, which is the smallest of the three sources of value and the one the client controls least.

Layer A — the AI the platform ships

This is the layer everybody evaluates. Capability built into the PMIS itself, operating on its records, inside its permission model, recorded in its audit trail.

Its great advantage is that it inherits the platform's governance for free. When an assistant built into the system searches records, it searches only what the user was already entitled to see, because it is using the same access control that governs every other part of the application. Nobody had to build that separately and nobody can accidentally bypass it. For a capital programme that inheritance is worth more than most of the features sitting on top of it.

PMWEB states the same principle in its Intelligence Control Framework, the governance architecture for AI in the two to disagree.

Its limitation is that it is defined by the vendor's judgement about what most customers need. Your organisation is not most customers.

Layer B — specialist capability joined to the platform

No PMIS vendor will ever be the best in the world at high-volume document capture. No document capture vendor will ever be the best at commitment management. These are different disciplines with different engineering problems, and the honest position is that a serious AI stack draws on both.

This layer covers two things in particular. At the front, capture and OCR, turning the paper and image estate into something structured. Above the platforms, reasoning that spans systems, because the questions that matter most in capital delivery rarely live inside one application. Which of my delayed activities have unapproved commitment changes behind them is a question that touches the schedule tool and the PMIS at once, and neither can answer it alone.

The trade at this layer is integration effort against specialist quality. Buying a bundled version of a specialist capability from a platform vendor usually means buying the weakest available version of it.

The trade has a governance side as well. A partner capability does not inherit the platform's controls automatically, so the questions a buyer puts to the platform vendor (whose permissions it honours, whether it reads your data or trains on it, what it logs) have to be put to the partner separately. Part III of this series returns to this.

Layer C — what you build yourself

This is the layer almost nobody evaluates, and it is where organisation-specific advantage actually accumulates.

Every PMIS client recognises the following experience. The question you genuinely need answered is not on the report menu. You raise an enhancement request. It is assessed, prioritised, scheduled, and arrives two releases later in a form that is not quite what you asked for. By then the question has changed.

Layer C is what happens when an organisation can point a general AI tool at its own project data and ask that question directly. Not through the vendor's roadmap. Not as an enhancement request. As an analysis, expressed in plain language, produced in an afternoon.

This layer is unbounded in a way the other two are not. Layer A is bounded by the vendor's product decisions.

Layer B is bounded by what partners have built. Layer C is bounded only by what your organisation wants to know, and by whether you can reach your own data well enough to ask.

Layer A is bounded by the vendor. Layer B is bounded by the partner. Layer C is bounded only by what you want to know.

The test that separates platforms

That last condition is the whole point, and it is where platforms differ far more than their feature lists suggest.

A platform that exposes your data only through a rate-limited interface has made a decision about who is allowed to analyse your project history, and the answer is the vendor. A platform that holds your data in a dedicated database with a documented schema has made the opposite decision. The feature comparison will not show you in your current system if you ever decide to move. For now it is enough to note that the question belongs on the evaluation list, and that it is almost never on it.

Why the model matters for evaluation

Assessing a platform on Layer A alone produces a predictable outcome. Every serious vendor is shipping broadly similar capability this year, the scores cluster, and the decision falls back to price or incumbency.

Assessing all three layers produces a different conversation. Layer A tells you what you get on day one. Layer B tells you whether the platform is a good citizen in a stack you will inevitably assemble. Layer C tells you who controls your project history, which is a question about the next ten years rather than the next release.

Layer A tells you what you get on day one. Layer C tells you who controls your project history, which is a question about the next ten years rather than the next release.

This series runs weekly in four parts. Part I establishes how AI on a PMIS should be judged. Part II covers what arrives with the PMWEB 2026 release. Part III covers the partner layer. Part IV covers the use cases organisations build for themselves, and what it takes to start. Next week: why every AI capability worth deploying in capital delivery stops and asks.