AI Agents in Project Delivery: Who Owns Accountability?
A project control system that suggests a recovery plan is useful. A system that issues the updated lookahead plan, notifies subcontractors, changes procurement priorities, and opens a contract notice draft has crossed a line.
That line is where AI stops being a reference tool and starts acting in project delivery.
Across oil and gas, EPC, construction, energy, infrastructure, mining, utilities, marine, and other capital-intensive sectors, AI agents are moving into practical project work. They can read unstructured documents, compare commitments, scan schedules, analyze risks, detect anomalies, draft reports, route approvals, and trigger workflows. Some are already connected to enterprise systems such as document management platforms, ERP tools, scheduling systems, contract registers, procurement portals, quality systems, and field reporting applications.
This is not science fiction. It is the logical next step after years of digitization. Projects already run on connected data environments, automated workflows, sensors, dashboards, and rule-based alerts. Generative AI and agentic systems add something different: the ability to interpret context, plan next steps, use tools, and act across systems with limited human direction.
That raises a hard governance question. When an AI-generated action causes delays, costs, safety issues, quality problems, or contractual consequences, who owns the outcome?
The answer cannot be “the AI”. Projects do not contract with algorithms. They contract with owners, contractors, suppliers, consultants, and joint venture partners. Accountability must still sit with people and organizations. Yet the path from human judgment to project action is becoming less direct. That is where experienced project leaders need new controls.
AI Agents Are Becoming Active Participants In Delivery
Traditional project software stores information, calculates values, or follows fixed workflows. Even advanced tools such as scheduling engines, cost systems, and document control platforms usually require people to decide what to do next.
AI agents change that model.
An agent can be given a goal, access to tools, and permission to complete tasks. It can break a goal into steps, retrieve information, compare options, recommend a path, and trigger actions. In project delivery, that could include:
Updating a draft schedule after progress data comes in from site.
Flagging contract clauses that may conflict with procurement terms.
Reviewing daily reports for early warning signs.
Drafting delay notices or change event summaries.
Comparing supplier quotations against technical and commercial criteria.
Creating risk register updates based on new field conditions.
Monitoring open actions and chasing responsible parties.
Identifying cost anomalies in commitments, purchase orders, or invoices.
Recommending workface planning changes based on material availability.
Opening a non-conformance workflow when inspection data falls outside tolerance.
None of these tasks is new. Project teams already do them every day. What is new is the speed, scale, and autonomy with which AI can perform them.
A planner may not have time to review every constraint in every work package each evening. An AI agent can scan progress data, material status, weather feeds, permits, labor availability, and equipment downtime, then propose a revised sequence before the morning coordination call.
A contracts engineer may review a package and spot a mismatch between payment terms and flow-down obligations. An AI system can compare hundreds of clauses across main contracts, subcontracts, purchase orders, insurance requirements, warranties, and correspondence, then highlight exposures that deserve review.
A procurement team may track supplier status through emails, portals, calls, and expediting reports. An agent can build a real-time view of supplier risk, draft follow-up messages, and escalate late responses.
The business case is clear. Complex capital projects suffer from fragmented data, slow reporting cycles, overloaded teams, and weak early warning signals. AI agents can help reduce administrative burden and improve visibility. They can also expose patterns that humans may miss.
The risk is just as clear. Once an AI agent can trigger actions, the project must treat it as part of the delivery system. That does not mean giving it personhood. It means recognizing that its outputs can affect real obligations, real interfaces, and real site activity.
A late material release may delay a critical path activity. A poorly drafted notice may weaken a contractual position. A mistaken anomaly alert may redirect scarce engineering time. A false confidence score may cause a team to underplay a safety risk. A procurement recommendation may favor a supplier based on incomplete data.
Project governance has long dealt with delegation. Engineers, planners, package managers, site supervisors, and contract administrators act within defined limits. AI agents now require similar discipline, but with one major difference: they do not understand accountability in the human sense. They lack professional judgment, a duty of care, commercial awareness, or moral responsibility. They process inputs and produce outputs.
That makes governance more important, not less.
Accountability Changes When Advice Becomes Action
A practical distinction exists between an AI system that advises and one that acts.
If an AI tool summarises a contract clause and a contracts manager chooses whether to rely on it, the accountability path is familiar. The tool supports analysis. The human remains responsible for the decision.
If an AI agent drafts a change notification, routes it for approval, attaches supporting evidence, sets response deadlines, and updates the claims register, the accountability path becomes more complex. The action may still need approval, but the agent has shaped the evidence, language, timing, and workflow.
If the same agent sends the notice automatically because the project configured it to do so below a certain value threshold, the accountability issue becomes sharper. The project has delegated operational authority to a system.
This matters because project delivery is full of decisions that look administrative but carry consequences.
A schedule update can affect float ownership, liquidated damages analysis, acceleration decisions, and subcontractor entitlement. A procurement ranking can affect technical compliance, warranty exposure, local content commitments, and long-lead equipment risk. A quality workflow can stop work or allow it to continue. A risk score can influence contingency, insurance, and executive reporting.
The more an AI agent participates in these processes, the less useful it is to describe it as “just software”.
Simple software follows explicit rules. If a user enters a quantity and a rate, the system calculates a total. If a workflow says approvals above a threshold go to a manager, it routes them accordingly.
AI agents can be less predictable. They may interpret text, infer intent, rank options, summarise trade-offs, or select a next step. Their outputs depend on training data, prompts, context windows, retrieval methods, integrations, and system settings. Two similar inputs can produce different answers if context changes.
That does not make them unusable. It makes them unsuitable for unmanaged authority.
A useful way to think about accountability is to separate four roles:
Accountability role | What it means in practice |
Business owner | Owns the process where the AI agent operates, such as planning, procurement, contract management, or quality. |
Technical owner | Owns configuration, integration, model selection, monitoring, and access controls. |
Decision owner | Approves actions that carry defined project, commercial, safety, or contractual impact. |
Assurance owner | Ensures the agent operates within policy, produces traceable outputs, and remains fit for use. |
In small deployments, one person may cover more than one role. In major projects, these roles should be explicit. The key point is that accountability cannot disappear into a generic “AI tool owner” label.
A project should also define whether an AI agent is performing one of three functions:
AI function | Typical use | Accountability stance |
Inform | Summarises, classifies, searches, or highlights issues. | Human user remains fully responsible for interpretation and next steps. |
Recommend | Proposes options, drafts documents, ranks risks, or suggests decisions. | Named decision owner must review and approve before impact. |
Act | Updates records, initiates workflows, sends communications, or changes system status. | Delegated authority must be formally approved, logged, monitored, and limited. |
Most organizations can start safely with “inform” and “recommend” use cases. The highest governance burden begins when the system can “act”.
The Hard Issues Project Leaders Need To Settle
AI accountability is not one issue. It is a cluster of operational, commercial, technical, and legal questions. The details will vary by contract, jurisdiction, corporate policy, and risk appetite. This article is informational only and is not legal advice.
The following areas deserve attention before AI agents become embedded in project workflows.
Authority Limits Must Be Written Down
Project teams already use authority matrices for spending, approvals, contract notices, technical queries, variations, concessions, and safety decisions. AI agents need the same discipline.
Authority limits should answer basic questions:
What can the agent read?
What can it draft?
What can it update?
What can it submit for approval?
What can it send externally?
What can it trigger without human approval?
What value, risk, or schedule thresholds apply?
Which activities are prohibited?
Some activities should remain outside AI authority unless strict controls exist. These include safety-critical decisions, legal commitments, contract notices, payment certification, claims submissions, design acceptance, and changes to approved construction methods.
That does not mean AI cannot support those activities. It can gather evidence, flag risks, and draft material for review. The difference is that a competent human owner must approve the action before it takes effect.
A useful control is to define AI authority levels, similar to delegated financial authority:
Level | AI authority | Example |
Level 0 | No project data access | Public knowledge assistant with no system connection. |
Level 1 | Read-only access | Searches approved project documents and summarises findings. |
Level 2 | Drafting and recommendations | Drafts reports, notices, risk updates, or procurement comparisons for review. |
Level 3 | Internal workflow initiation | Opens internal actions, assigns review tasks, or updates non-critical registers. |
Level 4 | Controlled transactional action | Makes defined updates in project systems within thresholds and with full logging. |
Level 5 | External or high-impact actions require strict approval and are used rarely | Sends external communications, changes contractual status, or affects site execution. This should require strict approval and be used rarely. |
The higher the level, the stronger the evidence, approval, testing, monitoring, and audit requirements should be.
Human Approval Must Mean Real Review
Many organizations will say they use a human-in-the-loop model. That phrase can create false comfort.
A human approval step is only useful if the approver has enough time, skill, context, and evidence to challenge the AI output. If the system produces dozens of polished recommendations each day and the approver clicks through them under pressure, accountability becomes ceremonial.
Effective human review needs:
Clear criteria for approval or rejection.
Access to source documents and data used by the agent.
A visible confidence basis, not just a confidence score.
Highlighted assumptions, missing data, and conflicts.
A record of what the human changed before approval.
Escalation routes for uncertain or high-impact items.
The approval workflow should also avoid automation bias. People tend to trust outputs that look complete, especially when they arrive in professional language and polished formats. AI agents can be persuasive even when wrong.
For high-risk actions, the system should require the human reviewer to confirm specific points. For example:
The relevant contract clause has been checked.
The schedule basis is current.
The affected package manager has been consulted.
The safety implication has been reviewed.
The commercial impact is within delegated limits.
This is slower than automatic approval, but it protects the project from hidden errors.
Data Quality Decides Output Quality
AI agents on capital projects often rely on messy data. Schedules may contain outdated logic. Procurement records may lag reality. Field reports may use inconsistent terms. Document metadata may be incomplete. Cost codes may not align across systems. Contract correspondence may sit in personal inboxes or unstructured repositories.
Poor data does not prevent AI from producing an answer. It often produces a confident answer based on weak inputs.
Project teams should treat data readiness as a core control. Before deploying an AI agent into a process, ask:
Which systems are authoritative?
How current is the data?
Who can change source data?
How are conflicts between systems resolved?
What metadata is required?
What data is excluded?
How does the agent handle missing evidence?
Can users see the sources behind an output?
An AI agent that monitors progress should know whether it is using approved baseline logic, current working schedules, contractor updates, or field observations. An agent that reviews contract risk should know which contract version is executed, which amendments apply, and which correspondence has contractual relevance.
Without this clarity, the agent may connect the wrong dots.
Auditability Must Cover The Full Chain Of Action
Project disputes often rely on records: who knew what, when they knew it, what they decided, and why. AI agents must not weaken that record.
A project should be able to reconstruct:
The user request or trigger.
The data sources accessed.
The model or agent version used.
The prompt, rules, or workflow applied.
The output generated.
The human review decision.
Any edits made before approval.
The action taken in a system.
The time, user, and approval trail.
Any later correction or override.
This applies to internal and external actions. If an AI agent drafts a delay notice, the project should retain the draft history, evidence links, reviewer comments, approval, and final issued version. If an agent changes a risk rating, the project should preserve the reason and source evidence.
Auditability also supports improvement. If the agent keeps making the same error, logs help teams identify whether the problem sits in data, configuration, prompt design, model behavior, or user training.
Transparency Should Match The Risk
Not every AI output needs a technical explanation. A summary of a daily report may only need links to the source. A recommendation to resequence critical work needs more.
Transparency should answer the practical question: can a qualified person understand enough to challenge the output?
For project use, transparency may include:
Source references.
Assumptions.
Excluded data.
Conflicting evidence.
Reasoning steps.
Alternative options considered.
Known model limitations.
Required approvals.
Some AI systems operate as black boxes, at least from the user’s point of view. That creates a problem for high-impact project decisions. If the project cannot explain why an agent recommended awarding a package to one supplier over another, or why it downgraded a risk linked to safety or quality, the recommendation should not carry decision weight.
Transparency does not need to expose confidential model code. It does need to provide enough reasoning, evidence, and traceability for responsible project governance.
Risk Does Not Stop At The Model
Many AI discussions focus on model accuracy. Accuracy matters, but project risk extends beyond the model.
An AI agent sits inside a wider system. It uses data, permissions, integrations, workflows, user prompts, retrieval tools, and approval logic. A failure in any part can create project consequences.
Cybersecurity Becomes A Project Control Issue
An AI agent with system access can become a high-value target. If it can read commercially sensitive documents, update project records, or trigger workflows, attackers may try to exploit it.
Risks include:
Unauthorized access to contract or pricing data.
Prompt injection through malicious documents or emails.
Data leakage through external model services.
Manipulated outputs that mislead project teams.
Compromised credentials used by the agent.
Excessive permissions across connected systems.
False approvals or workflow triggers.
AI agents should follow the same security principles used for other critical systems, with extra care around language inputs and retrieval sources.
Controls include least-privilege access, segregation of duties, secure authentication, approved data environments, logging, monitoring, and incident response procedures. The agent should not inherit broad admin rights because integration was easier that way.
Cybersecurity and project controls must work together. A cyber event can become a contractual event, a safety event, or a delay event. AI governance should sit inside the project’s risk and assurance framework, not in a separate technology lane.
Commercial Confidentiality Needs Clear Boundaries
Capital projects involve sensitive information: tender prices, claims strategy, design issues, supplier performance, legal advice, personal information, and joint venture data. AI agents can create confidentiality problems if they access, combine, or transmit information without proper controls.
A contract review agent may need access to executed agreements but not privileged legal correspondence. A procurement agent may need technical bid data but not confidential pricing from competing bidders unless the process permits it. A reporting agent may need project status but not unresolved claims strategy.
Project teams should classify data and control AI access by role and purpose. Just because an agent can search everything doesn't mean it should.
External communications also need care. If an AI agent drafts an email to a supplier using internal risk notes, those notes may accidentally appear in the message. If a reporting agent summarises claims exposure into a client-facing update, it may disclose more than intended.
Good governance requires review gates for sensitive content and rules that prevent the agent from mixing data across commercial boundaries.
Model Limitations Should Be Visible
Large language models can produce fluent but incorrect answers. They can miss context, misread tables, invent references, or fail to understand a term's contractual meaningJust because an agent can search everything doesn'. They can also struggle with specialization. Just because an agent can search everything doesn't mean it understands ited drawings, poor scans, ambiguous instructions, and local project practices.
Other AI models have their own limits. An anomaly detection model may flag unusual cost patterns but miss the commercial reason behind them. A predictive schedule model may identify risk patterns from historic data but fail when a project has unique constraints. A computer vision model may detect missing PPE in some conditions but perform poorly in dust, glare, or low light.
These limits should be documented for each use case.
A model card or AI use case sheet can capture:
Intended use.
Prohibited use.
Data sources.
Known limitations.
Test results.
Required human review.
Escalation criteria.
Monitoring method.
Owner and approval date.
This does not need to become paperwork for its own sake. It gives project teams a shared understanding of where the agent can help and where it must not be trusted alone.
Error Detection Must Be Designed In
Humans will not catch every AI error by reading outputs. Error detection needs system design.
For example, you could test a schedule agent against rules that flag negative float changes, missing logic, excessive activity-duration changes, or unapproved baseline edits. A contract agent could check whether the source document includes citations. A procurement agent could flag when recommendations rely on missing technical clarifications. A cost agent could compare outputs against authority limits.
Projects should use a mix of controls:
Automated validation rules.
Sampling and independent review.
Exception reports.
User feedback loops.
Periodic performance testing.
Drift monitoring when project conditions change.
Red-team testing for misuse and prompt injection.
Stop buttons that allow users to suspend an agent quickly.
The goal is not perfection. The goal is early detection before small errors become project events.
When AI Causes Harm, The Project Still Needs An Accountable Owner
The hardest cases arise when AI-generated actions cause consequences.
A delay notice goes out late because the AI agent failed to identify the triggering event. A supplier is selected based on an incomplete technical comparison. A workflow releases work before an inspection hold point is cleared. A forecast understates cost exposure and senior leaders delay corrective action. A report sent to a client contains incorrect progress figures. A safety trend is missed because site reports used inconsistent terminology.
In each case, the organization may be tempted to blame the tool, the vendor, the data, or the user. Those factors may matter. Yet project accountability must trace back to decisions people made before the event:
Who approved the AI use case?
Who defined its authority?
Who accepted the data quality risk?
Who configured access and workflow permissions?
Who decided human approval was or was not required?
Who monitored performance?
Who trained users?
Who reviewed incidents and corrected the system?
This is similar to other project systems. If a cost system is configured incorrectly, the project cannot simply blame the database. If a permit workflow allows the wrong work to proceed, the project examines process design, supervision, assurance, and system controls. AI deserves the same treatment, with extra attention to autonomy and opacity.
Contractual responsibility will depend on the specific contract, governing law, procurement model, and facts. Parties should avoid assuming that AI use transfers responsibility away from contractual obligations. If a contractor uses an AI agent to manage notices, the contractor may still carry the risk of late or defective notices. If an owner’s AI-driven approval workflow delays responses, the owner may still face consequences under the contract. If a consultant relies on AI outputs in professional services, normal standards of care may still apply.
That is why AI governance should be reflected in project documentation, not left as an IT matter.
Contracts and project procedures may need to address:
Whether AI tools may be used for defined activities.
Disclosure requirements for AI-generated submissions.
Human approval requirements for formal communications.
Records and audit trail obligations.
Data security and confidentiality rules.
Restrictions on using project data to train external models.
Responsibility for errors in AI-assisted outputs.
Rights to inspect logs after disputes or incidents.
Requirements for suspension if the AI system behaves unexpectedly.
These clauses will vary. The broader point is simple: if AI agents affect delivery, contracts and governance should say how.
Practical Governance Starts Before Deployment
Many organizations will adopt AI agents gradually. A team may start with report drafting, then connect the agent to document control, then let it open actions, then enable workflow triggers. Risk often grows through small steps.
The safest approach is to govern the capability before it expands.
A practical AI control framework for project delivery should include the following elements.
Map The Process Before Adding Autonomy
Start with the real process, not the technology demo.
For each use case, document:
The project process affected.
The current decision points.
The existing authority matrix.
The data sources used.
The systems touched.
The possible project consequences.
The internal and external stakeholders affected.
The records needed for audit or dispute purposes.
This mapping often reveals that a “simple” AI use case sits inside a contractual or safety-critical process. For example, drafting a weekly report may affect client expectations, progress certification, early warning duties, and claims records. Managing actions may affect closeout obligations or commissioning readiness.
Categorize Use Cases By Impact
Not all AI use cases require the same level of control. A low-risk internal summary does not need the same treatment as an AI agent that changes procurement status for critical equipment.
Classify use cases by potential impact:
Safety and environmental impact.
Contractual impact.
Cost impact.
Schedule impact.
Quality impact.
Regulatory impact.
Commercial confidentiality impact.
Reputation impact.
The classification should drive requirements for authority, approval, logging, testing, and assurance.
Define Decision Rights In Plain Terms
Decision rights should be specific enough that users know what the AI agent can and cannot do.
For example:
The agent may draft internal risk updates, but the risk owner must approve changes to risk rating or mitigation status.
The agent may identify potential delay events, but the contracts manager must approve any notice or reservation of rights.
The agent may rank supplier responses, but the procurement lead and technical authority must approve evaluation outcomes.
The agent may open internal actions for missing documents, but it may not issue external non-compliance letters.
The agent may recommend resequencing, but the construction manager must approve changes affecting critical path or safety interfaces.
This avoids vague language such as “AI may support project controls”. Support means little unless authority is defined.
Keep Humans Responsible For High-Impact Judgment
AI can assist judgment, but humans should lead high-impact judgment. That includes decisions involving safety, contractual rights, design acceptance, commercial commitments, and significant schedule or cost consequences.
Human review should not be the final thin layer after automation has already shaped the outcome. Integrate it into the process at the points where judgment matters.
For example, an AI agent can pre-screen delay causes and assemble evidence. The project contracts lead should still decide whether the event meets notice requirements. The planner should assess schedule logic. The package manager should confirm field facts. The project manager should approve the strategy if the issue is material.
This may sound like current practice because it is. AI should strengthen disciplined project management, not bypass it.
Test With Project Scenarios, Not Generic Prompts
Generic AI testing tells you little about project risk. Use realistic scenarios drawn from the project environment.
Test cases might include:
Conflicting schedule updates from contractor and site reports.
A contract clause with an amendment that changes notice periods.
A supplier quotation with missing exclusions.
A non-conformance with incomplete inspection records.
A progress report that conflicts with earned value data.
A potential safety issue buried in daily narrative text.
A change request where cost and schedule impacts do not align.
The aim is to observe how the agent behaves when data is incomplete, inconsistent, or sensitive. That is real project life.
Monitor Performance After Go-live
AI governance does not end at deployment. Models, data, users, and project conditions change.
Projects should monitor:
Error rates.
User overrides.
Approval rejection rates.
Unusual workflow volumes.
Complaints or disputes linked to AI outputs.
Security alerts.
Data access exceptions.
Model or integration changes.
User feedback.
A monthly review may suit some use cases. High-impact agents may need closer monitoring. If the system changes or project risk increases, review authority levels.
Prepare An Incident Response Plan
If an AI agent causes or contributes to a project issue, the team needs a response plan.
The plan should cover:
Suspending the agent or specific permissions.
Preserving logs and outputs.
Notifying relevant project leaders.
Reviewing affected actions and communications.
Correcting project records.
Assessing contractual notice requirements.
Informing counterparties where required.
Fixing data, configuration, or process weaknesses.
Deciding whether the agent can restart.
This should connect to existing incident, quality, cybersecurity, and contract management procedures. AI incidents can cross all of them.
The Accountable Project Will Treat AI As Delegated Capability
AI agents will not replace the need for project accountability. They will test whether accountability is real.
Complex projects already depend on delegation.
AI agents add a new form of delegated capability. They can work across data at a speed and scale that humans cannot match. They can reduce manual effort and improve early warning. They can also act on flawed data, misread context, expose confidential information, or trigger the wrong workflow before anyone notices.
The essential question is not whether projects should use AI agents. They will. The question is whether organizations will give them authority before they have built the controls that authority requires.
A responsible project organization should be able to state, for every AI agent in delivery:
What it is allowed to do.
What it is not allowed to do.
Who owns the process.
Who owns the technical controls.
Who approves high-impact actions.
What evidence supports each output.
How errors are detected.
How actions are audited.
How the agent can be stopped.
Who answers when something goes wrong.
That is the standard project leaders should set before AI agents become normal members of the delivery environment.
The best outcome is not a fully autonomous project. It is a project where AI handles the work it is suited to, people keep ownership of judgment and consequences, and the record is clear enough to stand up under pressure. Design accountability into the system before the first AI-generated action affects the field, the contract, or the bottom line.
