Seven Questions to Answer Before AI Touches Your Project Data

AI deployments in capital delivery organisations do not usually fail during evaluation. They fail after signature, in the gap between the project team who wanted the capability and the audit committee, IT governance function or legal team who were asked to approve it late and had no good answers to work with.

The seven questions below are the ones that arrive at that point. They come up in every serious evaluation, they are usually answered in passing during the demonstration, and they are the questions that stop deployments.

They are worth taking into a vendor meeting deliberately, in writing, early enough that the answers can be tested.

What follows is each question, what a good answer sounds like as distinct from a reassuring one, and the position PMWEB has stated on each.

PMWEB has since published its own version of this exercise, a six-question checklist for owners and construction managers titled Six Questions to Ask Before You Put AI Near Your Project Data. Where its questions sharpen what to require, that is noted below. The two questions it asks that are not on this list are covered at the end.

AI deployments in capital delivery organisations do not usually fail during evaluation. They fail after signature.

• Is our data exposed to external AI services?

A reassuring answer says the platform takes security seriously. A good answer tells you where the data goes.

This is the first question every IT function asks and it usually determines whether the conversation continues. What you are establishing is whether project data leaves the platform's boundary to be processed, and if so, where it goes and under what terms.

PMWEB's stated position is that customer data remains contained within PMWEB and is not exposed to outside the data goes, whether it leaves your tenant, how long it is retained, and whether it is used to train models shared with other organisations. Then ask whether those answers are in the contract. An answer that appears only in the sales deck is a red flag by the vendor's own definition. What you want is written terms confirming, for example, that change order and pay application data will not be used to train models serving anyone else.

• Can the AI see data a user cannot?

This is the question most often answered too quickly, and it is harder than it sounds.

A search that spans records is straightforward to permission. A search that spans records and workflow comments, and then assembles a combined summary connecting activity across several linked records, is not. The risk is that the synthesis reveals something none of the individual sources would have revealed to that user. An organisation with a properly segregated programme structure, where commercial teams on different projects are deliberately walled from one another, should test this specifically rather than accept a general assurance.

PMWEB's stated position is that AI access follows existing platform permissions, and that results are permission- filtered including where they connect activity across linked records.

The checklist frames the requirement precisely: AI should work under the permission model the owner already administers, not a second one. Restricted claim positions, confidential vendor pricing and contract values visible only to some staff must not surface in an AI summary prepared for someone who cannot open the underlying records.

• Can the AI change records without a human?

The answer you want is no, and you want to see it rather than hear it.

Ask for a demonstration that ends in the AI preparing something, and watch what happens next. Prepared updates should remain visibly pending. A drafted record should require an explicit save. The distinction between the system having done something and the system having proposed something should be obvious on screen to a user who is not paying full attention, because that is the condition under which most work is actually done.

PMWEB's stated position is that the assistant will not finalise an action such as saving a record without explicit user approval, and that prepared updates remain pending until saved or cancelled.

The checklist names the person at the end of the chain. AI output should go through the same approval workflow as any other submission, with a named human approver before anything is actioned. Its version of this question is the shortest on either list: who signs?

• Is AI activity in the audit trail?

A capability that acts on your records and is not recorded in the audit trail has created a category of event your control environment cannot see.

What you are looking for is that AI-assisted actions are audited to the same standard as any other action, and specifically that the trail names the person who approved rather than the assistant that prepared. This matters most in the situation nobody plans for, which is a dispute two years later where the basis of a decision has to be reconstructed.

PMWEB's stated position is that permission controls and a full audit trail are retained as automation increases.

The checklist is specific about what the log should hold: the user, the timestamp, the query, the response and the resulting action. It also gives the test case. If someone asks later why contingency was drawn down in March, the record should show what was asked of the AI, what it returned, who reviewed it and what they decided. Ask alone does not show what the approver was told. "The system suggested it" is not an answer that survives a dispute.

A capability that acts on your records and is not recorded in the audit trail has created a category of event that your control environment cannot see.

• Can it be switched off?

This is the underrated question on the list.

An all-or-nothing capability forces an organisation into a single decision it is not ready to make. Capability that can be enabled individually allows a phased rollout, which is the only kind that survives contact with a large programme. It also allows a restricted-scope deployment, where a capability is available to a commercial team and not to a site team, or enabled on one programme while another is mid-audit.

Ask what the unit of control is. Per capability, per user group, per project, per environment. The answer determines how much of your rollout you actually control.

PMWEB's stated position is that each AI capability can be enabled or disabled individually.

• Will it alter the data model?

An AI that creates relationships between records to improve its own analysis is altering the structure of your project data, and it is doing so on the basis of inference.

The distinction to establish is between surfacing a relationship for analysis and creating one in the system. The first is analysis. The second is a change to the record, and it should require a person.

PMWEB's stated position is that relationships can be surfaced for analysis, but creating a link requires a deliberate user action.

• Is there a published governance framework?

The difference between a vendor with a governance framework and one without is not the presence of a document.

It is whether the answers to the previous six questions are design commitments or current behaviour.

Current behaviour changes without notice. A design commitment is a position the vendor has published and can be held to. Ask for the framework, ask when it was published, and ask what in it constrains the product roadmap.

PMWEB's published AI governance architecture is the Intelligence Control Framework, which defines how AI capabilities are designed, deployed and governed within the platform.

In its September 2026 checklist PMWEB describes the framework as covering three things: what AI can access, how AI stays bound by existing permissions, and where human judgement stays in the loop. It says the framework was built to answer governance questions of this kind structurally rather than case by case, and states its guiding principle in five words: AI advises, the operator decides. That is the shape of a design commitment. The test is still the one above: ask for the document, its date, and what in it constrains the roadmap.

Vijai Viswanathan, PMWEB's Chief Product and Technology Officer, put the balance plainly when the checklist was published: the potential of AI in capital project management is enormous, but so is the responsibility.

Two things are worth obtaining from any vendor in written form rather than as demonstration commentary, because both will be relied upon later.

The first is what happens to your data. Not only whether it leaves the platform, but whether it is used to train or improve models, and how long AI-related data is retained. This is the question the audit committee asks, and a verbal assurance in a demonstration is not something an audit committee can accept.

The second is whether AI usage is metered. Several platforms are introducing token, query or per-seat allowances for AI capability. An allowance changes rollout fundamentally, because a capability people are told to ration does not get adopted at all. PMWEB has stated that AI usage carries no limit.

Two more questions, from the vendor's own checklist

The seven questions above are the ones that stop deployments after signature. Two of PMWEB's six are not on this list, and they are worth adding because they expose a weak capability before it gets that far.

Can it show the source record behind every number?

Every figure the AI produces, whether a cost forecast, a schedule risk score or a contract summary, should link to the record behind it, ideally in one click. A forecast that cites the pay application or schedule revision it rests on can be checked by the reviewer. A figure with no traceable source can only be believed or disbelieved, and nobody in capital delivery should have to make that choice.

Does it work on your actual records?

Ask for the demonstration to run on live programme data (commitments, change orders, RFIs, submittals, cost and schedule) rather than on a curated document set or files uploaded to a chat window. A capability that performs well on a prepared sample and has never been run against an active programme has not yet been tested on what you are buying it for.

Using the list

Send the seven questions, and the two above, before the demonstration rather than after it. Ask for written answers. Where a vendor tells you that an answer is still being worked through, that is a more useful response than a general assurance, and it should be recorded as such rather than treated as a failure.

Any vendor whose answers to these seven are solid has told you something important about how they think, and it will be visible in the rest of the product.

Send the seven questions before the demonstration rather than after it, and ask for written answers. A vendor giving you a complete set of positive answers is not describing a product.

That concludes Part I of this series. Part II examines what the PMWEB 2026 release brings, beginning with the on-demand assistant.