AI Safety in Project Portfolios: A PMO Guide

Adoption ran ahead of governance. That's the short version.

Most enterprises now have AI touching project work somewhere. Status narratives get drafted by a model. Risk logs get summarized. Somebody in finance is quietly running forecast scenarios through a chat interface. Meanwhile the PMO's governance framework was written before any of that existed, and it says nothing about which decisions a model may influence, who signs off, or what evidence gets kept.

That gap is where AI safety lives for project professionals. Not in the abstract questions about model alignment that dominate the general conversation, but in a much more prosaic set of questions. What is this system allowed to see? What is it allowed to change? Who reviewed its output before it moved money or people, and can you show that they actually reviewed it?

Those questions now have legal weight in several jurisdictions, and they're becoming procurement questions too. Worth getting ahead of.

The regulatory ground is moving, unevenly

Two developments matter most for portfolio governance, and both are more nuanced than the summaries going round LinkedIn suggest.

The EU AI Act came into force in August 2024 and has been arriving in stages since. Prohibitions and AI-literacy duties applied from February 2025, with obligations on general-purpose models following that August. Across most of the Act, obligations are tiered by what a system is used for. An assistant drafting a status summary sits in a very different category from one influencing recruitment, promotion, task allocation or performance evaluation — all of which Annex III treats as high-risk uses of AI in employment. General-purpose models are handled under a separate chapter and tiered partly by capability rather than use, which matters if you are building rather than buying.

Timing deserves care, in both directions. The stand-alone high-risk obligations that would have applied from August 2026 were pushed back to December 2027 under the Digital Omnibus package, so immediate pressure on the employment tier is lighter than it looked a year ago. Transparency duties were not deferred. And there's a trap in reading a delayed deadline as permission to wait, since the systems most likely to be caught are also the ones that take longest to make defensible.

In the UK, the Data (Use and Access) Act 2025 put the phrase “meaningful human involvement” into statute, with section 80 fully in force from February 2026. It's worth reading what the Act actually does, because it gets described backwards fairly often. It relaxes the previous general prohibition on solely automated decision-making for most personal data, replacing it with a safeguards regime. Where a significant decision — one with legal or similarly significant effects — is taken about someone without meaningful human involvement, the organization has to inform them, allow representations, provide human intervention, and let them contest the outcome.

So the operative standard isn't “get a human to approve everything.” It's narrower and more useful than that. Know which of your decisions are significant ones about individuals, and know whether a human is genuinely in the loop for those. A reviewer who lacks either the authority or the information to reach a different conclusion isn't meaningful involvement, whatever the approval log records.

Neither regime asks organizations to stop using AI. Both, in different ways, ask them to be able to account for what happened — and that account isn't something you can assemble retrospectively.

Where the risk actually sits in a portfolio

The dramatic AI risks get the headlines. The ones that actually bite a PMO are duller and much more likely.

Confident output over incomplete input. A model summarizing a portfolio produces an equally fluent summary whether it can see all two hundred projects or forty of them, and nothing in the output signals the gap. In our experience this is the one that bites most often, and it's rarely caught, because the summary reads perfectly well.

Silent scope creep in what the model can reach. An assistant granted access to “project data” in week one may, after a few integration changes and a schema update nobody flagged, be reading commercial terms, resource costs and individual utilization figures. Access that was proportionate at setup stops being proportionate as the system around it grows, and nothing prompts a re-review.

Recommendations that arrive without their assumptions. A model suggests deferring an initiative. Fine — on what basis? If the reasoning can't be reconstructed, a governance board is being asked to ratify a conclusion it cannot interrogate.

Automation of the wrong step. Drafting a status report is low risk and high value. Reallocating funded capacity is neither. Organizations blur the two because both get described as “AI in the PMO,” which is about as useful a category as “software in finance.”

Drift. The system that behaved well in a pilot may behave differently six months later, after the vendor updated the model, the data patterns shifted and three more integrations came online.

None of that requires a malicious actor or an exotic failure mode. These are ordinary operational risks that happen to involve a model.

Coverage is a safety property before it is a reporting one. One live portfolio built from every connected delivery tool is what stops an analysis being confidently partial.

The agentic problem is a scope problem

Agentic AI — systems that take actions rather than only producing text — moves fastest and is governed least. Gartner forecast in mid-2025 that over 40% of agentic AI projects would be cancelled by the end of 2027, on the basis of escalating costs, unclear business value or inadequate risk controls. Take the precise figure or leave it. The direction matches what most enterprises are finding, which is that the technology currently works better than the governance wrapped around it.

For a PMO, the useful reframing is that agentic risk is mostly a scope question. An agent isn't dangerous because it reasons; it's dangerous when the set of actions available to it is wider than the set anyone intended it to have.

That turns into a handful of practical questions, all worth asking before an agent goes near a live portfolio.

What can it read? Not in principle — specifically. Which projects, which fields, whose resource records, which financial data.

What can it write? A read-only agent that surfaces risks is a fundamentally different governance object from one that can change a project stage or reassign work. Treat them as different systems, because they are.

Whose authority is it acting under? An agent that operates with a service account holding administrative rights has effectively removed permissions from the equation. An agent that acts as an identified user, inheriting exactly that user's permissions, has not.

What does it leave behind? If the agent takes an action, is there a record naming what changed, when, under whose authority, and what prompted it?

Answer those four and most agentic governance follows. Skip them and no policy document will help.

What MCP changes, and what it does not

The Model Context Protocol has become the common way to connect an AI assistant to a business system. It's worth understanding what it actually is, because it's frequently described in ways that overstate the magic.

An MCP server exposes a defined set of tools to an assistant. Each tool does one specific thing: fetch a list of projects, retrieve a single idea, create a task. The assistant can call those tools and nothing else. It cannot browse the underlying database, cannot construct its own queries, and cannot reach functionality that wasn't exposed.

That constraint is the governance property worth caring about. The tool surface is the permission boundary, and unlike a natural-language policy, it's enforced rather than requested.

Two things MCP does not do on its own, and both matter.

It doesn't authenticate by itself. The security model depends entirely on how the server handles identity. A server that acts as the signed-in user and inherits that user's permissions behaves very differently from one that runs with a broad service account, even though both look identical from the assistant's side.

It doesn't distinguish reading from writing unless someone deliberately designs that in. A tool surface mixing retrieval and mutation with no separation gives you an agent that can quietly change things while appearing to answer questions.

Which makes “do you support MCP” a fairly weak procurement question, given how quickly support is spreading. The questions with teeth: whose identity does your MCP server act under, which tools read and which ones write, and what does the audit trail look like afterwards.

Governance does not end at procurement

Governance effort tends to concentrate at the point of adoption — the assessment, the sign-off, the procurement questionnaire. Far less attention reaches the years afterwards, which is where exposure quietly accumulates.

Systems drift. Vendors update models, sometimes with little notice and rarely with a changelog you can map onto your risk assessment. The data underneath changes shape as integrations are added and teams change how they log work. Operational reality diverges from the conditions the system was evaluated under. And the people who understood the original assessment move on.

Practically, this means a few unglamorous habits. Re-review AI-assisted governance processes on a fixed cadence, the same way you'd review any control. Keep a register of which AI capabilities are in use, what they touch, and who owns each one — treat it like a supplier register, because functionally it is one. Sample the outputs periodically rather than assuming continued accuracy. And when a vendor ships a significant model change, treat it as a change to your control environment, not just a product update.

None of this is exciting. It's the difference between being able to answer a regulator's question and not.

Meaningful human involvement, in practice

The phrase gets treated as a compliance formality. Treat it as a design constraint instead, because building for it costs far less than retrofitting it later.

Involvement is meaningful when the reviewer is competent to evaluate the output, which means they understand the domain rather than that they're senior. It also requires that they hold both the authority and the information to reach a different conclusion. A reviewer who can only agree is a formality with a job title.

Documentation is where organizations tend to be thinnest, and it's the part worth arguing about. Strictly, the UK statute doesn't spell out a reasoning log — that requirement is an accountability inference rather than a line you can point to. It's also the cheapest control available and the one that will do the most work if anyone ever asks. A short note capturing why a recommendation was accepted or rejected costs a reviewer half a minute. It tends to improve the decision as a side effect, since writing down a reason is a reliable way to discover a weak one.

One related trap is worth naming, though the evidence is messier than it's usually presented. People don't respond to machine advice uniformly. In some settings they over-trust it and stop checking; the automation bias literature going back to the 1990s documents that well. In others the opposite shows up — the algorithm aversion research, notably Dietvorst and colleagues in 2015, found people discounting algorithmic advice relative to human advice, and discounting it far harder after seeing the algorithm err once. Which way a given team leans depends on the task, their expertise, and their history with the tool.

So assume neither. Build the review step so it works whichever way your people lean: surface the inputs next to the conclusion, ask for a stated reason, and check occasionally whether reviewers ever disagree with the system. A review process that has never produced a rejection isn't evidence that the system is right.

What PPM Express does about it

Our approach starts from a position that sounds modest and isn't: AI in portfolio management should be grounded in live data, and it should operate inside the permissions the organization already defined.

AI insights and status reports are generated from the portfolio data PPM Express already aggregates across every connected delivery tool. That coverage is the safety property, not a feature bullet. An analysis drawn from the whole portfolio can be wrong; an analysis drawn from one connected tool is structurally incomplete and reads exactly the same.

AI agents analyze project data continuously and can execute routine tasks inside defined rules — flagging new risks, surfacing late milestones, recommending schedule adjustments. They remain subject to project manager approval. The boundary is deliberate. Agents do the monitoring that humans do badly, and humans keep the decisions that matter.

The MCP servers are where the scope questions above get concrete answers. PPM Express exposes portfolio data to assistants such as Claude and ChatGPT through MCP servers covering projects and ideation. Two design choices are worth spelling out for anyone assessing them.

The server acts as an identified PPM Express user. It resolves the acting user and their linked resource record, and every call runs inside that user's permissions. It is not a privileged back door into the tenant. If a person cannot see a project in the application, the assistant acting on their behalf cannot see it either.

The tool surface is explicit and separated. Retrieval tools return projects, project items, tasks, ideas, challenges, resources and summary views. Creation and update tools — creating or updating a project, a task, an idea, or advancing an idea's stage — are distinct, named operations rather than a general write capability. Records returned carry links back to the item in PPM Express, so a recommendation can be traced to the underlying record rather than taken on trust.

The other half of the picture. An assistant can only reason about whether something matters if the criteria exist as data — which is what scoring models and the wider governance layer provide. Hosting, access control and data handling are covered separately under security and trust.

That combination gives a PMO something concrete to govern with, rather than a policy about a black box. The permission boundary is the one your organization already defined and already maintains. The action surface can be listed on a page, which means it can be reviewed by someone who is not an engineer. Audit falls back on the application's own record of what changed and who changed it.

Judgment is still required. What changes is that the judgment gets applied to complete information, inside a boundary somebody chose on purpose.

A practice checklist for PMOs

Eight things worth working through before AI goes anywhere near portfolio decisions.

1. Map your exposure by use, not by tool. Which AI-assisted processes bear on individuals? Annex III of the EU AI Act is specific here: recruitment and selection, promotion and termination, performance and behaviour monitoring, and task allocation based on individual behaviour or personal traits. Ordinary capacity planning is not automatically caught. An assistant that ranks named people for assignment on inferred characteristics is a different matter, and is also the most likely candidate for a significant decision under the DUAA.
2. Write down what “meaningful review” means for each process. Who is competent to review it, what they need to see, and what they must record. Vague sign-off will not survive scrutiny.
3. Separate read from write. Inventory every AI capability by whether it can change state. Govern the two categories differently.
4. Check whose identity the system acts under. Service accounts with broad rights defeat the permission model you already built. Identity-scoped access preserves it.
5. Demand coverage transparency. For any AI-generated analysis, be able to state what data it could see. Confident output over partial coverage is the failure that hides best, since nothing in the writing gives it away.
6. Keep an AI register. Capability, owner, data touched, last review date. Same discipline as a supplier register.
7. Re-review on a cadence. Models change, data drifts, integrations multiply. A one-time assessment ages badly.
8. Design for the audit you'd want. What changed, when, under whose authority, on what basis. If you cannot reconstruct that from the record, the control does not exist yet.

None of this is a reason to move slowly. It is a reason to be able to answer three questions on demand: what can our systems see, what are they permitted to change, and who decided. A PMO that can still answer those a year later — after the people who set it up have moved on and the vendor has shipped four model updates — is in a position to keep adopting.

One that cannot is not being cautious. It is simply unaware of its own exposure, which is a worse place to be than slow.