Private Enterprise AI for Construction: How ProjectVIEW AI Turns ERP Data into Governed Intelligence

Enterprise AI should not force companies to choose between data sovereignty and access to advanced artificial intelligence.

 

• Construction companies,
• EPC contractors,
• Shipyards,
• Offshore contractors,
• Mining companies and
• other project-driven enterprises

 

hold some of their most valuable intellectual property inside their ERP systems: estimates, BoQs, WBS structures, productivity rates, supplier quotations, procurement history, contracts, claims, project costs, engineering records and commercial data.

 

 

At DANAOS Projects, our strategy for ProjectVIEW AI is different:

 

Keep control of the data. Own the business context. Govern access. Use the appropriate AI reasoning engine for the task.

 

ProjectVIEW ERP remains the operational system of record and the source of business context. AI becomes a governed intelligence layer operating against that context.

 

That distinction is fundamental.

 

What Is ProjectVIEW AI?

 

ProjectVIEW AI is the intelligence and agentic automation layer of ProjectVIEW ERP, designed to apply AI reasoning to structured, project-specific enterprise data and workflows.

 

ProjectVIEW ERP provides the operational foundation:

 

BoQ ↔ WBS ↔ Cost Codes

 

These dimensions connect commercial scope, time, resources, cost and actual project execution.

 

ProjectVIEW ERP already supports processes including:

 

• Estimation and Tendering
• Budgeting and Cost Control
• Procurement
• Subcontractor Management
• Contracts and Commercial Management
• Materials and Production
• Machinery and Fleet
• HR and Payroll
• Site Operations
• Project Controls
• Document Management
• Financial Management

 

ProjectVIEW’s published product documentation describes this integrated environment and the association of BoQ, WBS and Cost Codes, together with actual-versus-budget cost monitoring and integrations with systems such as Oracle Primavera P6 and Microsoft Project.

 

ProjectVIEW AI builds intelligence on top of that operational foundation.

 

 

Why Does ERP Need to Come Before AI?

 

The quality of enterprise AI depends heavily on the quality, structure and context of the information available to it.

 

A generic AI model may understand what a purchase order is.

 

But it does not inherently understand:

 

• which project requires the material;
• which BoQ item created the requirement;
• which WBS activity requires it;
• which cost code should absorb the expenditure;
• what quantity was budgeted;
• what has already been committed;
• what has actually been consumed;
• which suppliers were previously evaluated;
• whether the purchase exceeds an approval threshold;
• whether the expenditure creates a cost deviation;
• and who has authority to approve the transaction.

 

That context already exists inside a properly structured Construction ERP.

 

This is why DANAOS has consistently argued that companies should establish the ERP and process foundation before attempting large-scale AI automation. ProjectVIEW ERP structures financials, procurement, contracts, projects and operations into a common operational environment.

 

For AI, that structured environment becomes extremely valuable.

 

Instead of asking an AI model to understand an unstructured collection of disconnected spreadsheets, emails, databases and documents, ProjectVIEW can provide controlled access to the relevant operational context required for a specific task.

 

What Is the DANAOS Enterprise AI Strategy?

 

The DANAOS strategy can be summarized in five words:

 

Keep the data. Orchestrate the intelligence.

 

We do not believe enterprises should surrender their proprietary operational knowledge to public consumer AI systems.

 

We also do not believe that every contractor, shipyard or engineering company needs to become an AI infrastructure company by purchasing and maintaining large GPU clusters.

 

Instead, ProjectVIEW is being developed around a model-flexible, enterprise-governed AI architecture.

 

The architecture separates five important layers:

 

1. System of Record — ProjectVIEW ERP

 

The ERP maintains transactions, workflows, budgets, contracts, procurement records, project structures and operational history.

 

2. Business Context — ProjectVIEW Business Logic

 

BoQ, WBS, Cost Codes, resources, contracts, approvals and actual project execution give enterprise data meaning.

 

3. Governance — Identity, Permissions and Security

 

AI access must respect the same organizational boundaries governing the underlying enterprise information.

 

4. Intelligence — Enterprise AI Models

 

Appropriate AI reasoning models can be selected according to the use case, security architecture, deployment requirements and commercial considerations.

 

5. Action — ProjectVIEW AI Agents

 

Purpose-specific agents can progressively move from answering questions toward investigating conditions, recommending actions and, where authorized, initiating controlled workflows.

 

The result is not simply an ERP connected to a chatbot.

 

It is the foundation for a Governed Agentic ERP.

 

Does Enterprise AI Require Sending ERP Data to Public AI Services?

 

No.

 

Enterprise deployments can use architectures specifically designed to separate enterprise customer data from public consumer AI services.

 

For example, Microsoft’s documentation for Azure AI / Microsoft Foundry states that customer prompts, completions, embeddings and training data for models sold by Azure are not made available to other customers or underlying model providers and are not used to train generative foundation models without customer permission.

 

Microsoft also states that these models are hosted within Microsoft’s Azure environment rather than interacting with services operated by the underlying model provider.

 

This distinction matters.

 

Using a frontier AI model does not automatically mean using a public consumer chatbot.

 

Enterprise architecture, identity management, data residency, retention configuration, model deployment and contractual controls determine how AI interacts with corporate information.

 

What About Data Residency?

 

Data residency requires more precise language than simply saying that information “stays behind the firewall.”

 

Microsoft documents several deployment models.

 

For standard or regional deployments, inference processing can remain within the selected deployment geography or region according to the deployment configuration. Data Zone deployments operate within their defined geographic zone, while Global deployments can process requests across eligible Azure regions.

 

Microsoft also states that data stored at rest remains within the designated Azure geography.

 

Therefore, enterprise AI architecture must deliberately consider:

 

Data location → Model deployment → Retention → Identity → Permissions → Network architecture → Auditability

 

Data sovereignty cannot be treated as a marketing checkbox.

 

It is an architectural decision.

 

Does ProjectVIEW Need to Train an AI Model on the Customer’s ERP Database?

 

Not necessarily.

 

This is another important distinction in the DANAOS AI strategy.

 

Enterprise AI does not always require taking a company’s complete ERP database and using it to retrain a foundation model.

 

Instead, the system can retrieve the information relevant to a particular request and provide that context to the model at inference time.

 

Microsoft describes this type of architecture as grounding AI responses using enterprise data. In its “On Your Data” architecture, relevant information is retrieved from the designated source and used to augment the prompt while the underlying source data remains in the data location selected by the customer.

 

For ProjectVIEW, this concept is especially powerful because the underlying information is already structured around project business logic.

 

Instead of giving an AI model indiscriminate access to everything, the system can provide the right context for the right task to the right authorized user.

 

Why Are BoQ, WBS and Cost Codes Important for Construction AI?

 

Because AI needs context.

 

A construction project is not simply a collection of accounting transactions.

 

A cost becomes operationally meaningful when the enterprise understands:

 

What was sold → What was planned → What was budgeted → What was committed → What was executed → What was consumed → What was paid → What remains

 

ProjectVIEW ERP connects these dimensions through:

 

BoQ ↔ WBS ↔ Cost Codes

 

DANAOS describes this structure as the project kernel connecting commercial scope, scheduling and cost information.

 

This provides AI with something much more valuable than isolated documents.

 

It provides structured project context.

 

Consider a simple management question:

 

“Why is this project losing margin?”

 

A generic chatbot cannot reliably answer that question from an isolated general ledger.

 

A project-aware AI environment can potentially investigate relationships between:

 

• estimated cost;
• budget revisions;
• procurement commitments;
• supplier prices;
• subcontractor certifications;
• labor productivity;
• machinery utilization;
• materials consumption;
• project progress;
• variations;
• claims;
• revenue;
• schedule deviation;
• actual cost.

 

That is the difference between AI attached to enterprise software and AI embedded in project business logic.

 

From AI Assistant to AI Agent

 

The first generation of enterprise AI primarily answered questions.

 

The next generation will increasingly participate in workflows.

 

That transition is important.

 

A ProjectVIEW AI Assistant might answer:

 

 

A ProjectVIEW AI Agent could go further:

 

 

For example, a procurement agent could detect that the latest supplier quotations materially exceed the budgeted rate.

 

It could then:

 

1. retrieve the relevant BoQ and budget;
2. review historical procurement information;
3. compare quotations;
4. identify the cost deviation;
5. assess the potential project impact;
6. recommend an appropriate action;
7. route that recommendation through the ProjectVIEW approval workflow;
8. execute the approved transaction through the ERP;
9. preserve the decision and transaction history.

 

The important word is approved.

 

Enterprise AI should not simply be autonomous.

 

It should be governed autonomous intelligence.

 

Why Human Approval Still Matters

 

ERP systems exist partly because enterprises require accountability.

 

A purchase order is not simply text.

 

A subcontractor certificate is not simply text.

 

A variation is not simply text.

 

These are commercial commitments.

 

They can affect cash flow, contractual liability, project margin and financial reporting.

 

That means enterprise AI must operate within established rules of authority.

 

NIST’s AI Risk Management Framework emphasizes incorporating trustworthiness and risk management throughout the design, deployment, use and evaluation of AI systems. NIST has also published a dedicated Generative AI Profile addressing risks specific to generative AI.

 

For ProjectVIEW, the practical interpretation is straightforward:

 

AI should operate inside enterprise governance—not around it.

 

ProjectVIEW’s AI Governance Principle

 

A useful way to understand the architecture is:

 

 

1. The identity determines the user.
2. The role establishes organizational responsibility.
3. Permissions determine what information and processes can be accessed.
4. ProjectVIEW supplies the relevant operational data.
5. AI reasons over the authorized context.

 

ProjectVIEW controls what actions can subsequently occur.

 

This matters because the same AI question can require completely different access rights.

 

A Project Manager, Procurement Manager, CFO, Quantity Surveyor and subcontractor should not necessarily receive the same information simply because they ask the same question.

 

ProjectVIEW already provides user, role and group access controls and workflow/business-process management as part of its ERP foundation.

 

AI therefore becomes another governed participant in the enterprise architecture.

 

What Are ProjectVIEW AI Agents?

 

The long-term ProjectVIEW architecture is based on purpose-specific AI agents rather than one universal corporate chatbot.

 

Potential areas include:

 

AI Tendering Agent

 

Supports historical analysis, cost estimation, bid preparation, risk identification and scenario evaluation.

 

AI Procurement Agent

 

Supports supplier intelligence, quotation analysis, historical price comparison, procurement planning and deviation detection.

 

AI Cost Control Agent

 

Investigates Actual vs Budget performance and identifies emerging cost anomalies.

 

AI Contract Agent

 

Supports analysis of contractual records, variations, claims, certifications, obligations and commercial documentation.

 

AI Project Controls Agent

 

Connects cost, progress and schedule information to help identify emerging performance deviations.

 

AI Machinery Agent

 

Supports utilization, maintenance, downtime and equipment-cost analysis.

 

AI Management Agent

 

Provides cross-project intelligence for executives operating complex project portfolios.

 

The objective is not to create more isolated applications.

 

The objective is to allow specialized AI agents to operate on a common enterprise data fabric governed by ProjectVIEW ERP.

 

Why Is Model Flexibility Important?

 

AI models are evolving extremely quickly.

 

For an enterprise software company, tightly coupling the entire AI strategy to one model would create unnecessary technological dependency.

 

 

It is the combination of:

 

ProjectVIEW business logic + structured enterprise data + workflows + governance + integration + AI orchestration.

 

The reasoning model can evolve.

 

The customer’s operational knowledge remains within the enterprise architecture.

 

This leads to an important distinction:

 

• The AI model provides intelligence
• ProjectVIEW provides context.
• Business logic provides meaning.
• Governance provides control.

 

That is a more durable enterprise architecture than betting the entire company’s AI strategy on whichever foundation model happens to lead the market today.

 

Why Not Simply Deploy a Local LLM?

 

Local AI models have valid use cases.

 

They may be appropriate where offline operation, highly restricted data environments, latency requirements or specialized workloads justify them.

 

 

DANAOS therefore does not view the choice as:

 

Public AI vs Local AI.

 

The better question is:

 

Which model and deployment architecture provides the required intelligence, security, governance, economics and data-residency characteristics for each enterprise workload?

 

This is why model flexibility is central to the ProjectVIEW AI strategy.

Security Is Part of the Architecture

 

AI security cannot be separated from ERP security.

 

ProjectVIEW ERP operates within an enterprise environment incorporating access controls, workflows and security mechanisms. DANAOS’ published SaaS framework describes a dedicated private environment approach, while DANAOS also publicly lists ISO certifications including ISO 27001 and ISO 27018.

 

At the AI infrastructure level, Microsoft states that Foundry data at rest is encrypted and that customer-managed keys can be used for supported services and configurations.

 

The important principle is therefore not simply:

 

“Our AI is secure.”

 

It is:

 

AI inherits and operates within an enterprise security, identity, data and governance architecture.

 

The ProjectVIEW “Reality Check”

 

AI is only valuable if the reality it reasons about is accurate.

 

This connects directly to the core business logic of ProjectVIEW ERP.

 

Every project process can ultimately be evaluated against two fundamental dimensions:

 

TIME — represented through the Work Breakdown Structure

 

and

 

COST — derived from the commercial and budget structure, including the Bill of Quantities.

 

Actual execution can then be continuously compared against what was planned.

 

 

• Procurement can be compared with budget.
• Subcontractor progress can be compared with certified work.
• Materials consumption can be compared with planned quantities.
• Labor and machinery can be compared with expected productivity.
• Actual project cost can be compared with budget and progress.

 

ProjectVIEW ERP already provides Actual-vs-Budget cost monitoring and site-data capture across labor, plant, materials and subcontractors.

 

AI makes that reality check significantly more powerful because deviations no longer need to remain passive numbers on a dashboard.

 

They can become events that trigger investigation.

 

From Business Intelligence to Machine Reasoning

 

Traditional ERP reporting answers:

 

What happened?

 

Business intelligence helps answer:

 

Where did it happen?

 

Predictive analytics asks:

 

What may happen next?

 

Agentic AI introduces another question:

 

What should we do about it?

 

That is where ERP and AI converge.

 

The AI model can reason.

 

But the ERP understands the organization.

 

It knows:

 

• the projects;
• the budgets;
• the contracts;
• the suppliers;
• the subcontractors;
• the resources;
• the approvals;
• the responsibilities;
• the transactions;
• and the actual project execution.

 

AI without this operational foundation risks becoming an impressive interface disconnected from commercial reality.

 

ProjectVIEW provides that foundation.

 

What Is DANAOS Building?

 

DANAOS is not trying to build another generic chatbot.

 

And our strategic objective is not to become a foundation-model company.

 

We are building an AI orchestration layer for project-driven enterprises.

 

 

Together, they form the architecture DANAOS describes as ProjectVIEW OS: an integrated operating environment for construction, marine and offshore engineering, shipbuilding, mining and other complex project-based industries.

 

The direction is clear:

 

Company-first architecture. Project-centric business logic. Purpose-specific AI agents.

 

What Is the Future of AI in Construction ERP?

 

The future is unlikely to be an AI chatbot sitting beside the ERP.

 

The more consequential evolution is AI operating inside ERP-controlled business processes.

 

That means moving from:

 

Search → Answer

 

to:

 

Observe → Understand → Reason → Recommend → Approve → Act → Audit

 

For construction and other project-based industries, this is particularly important because project profitability depends on thousands of interconnected decisions involving cost, time, resources, contracts and operational execution.

 

AI can accelerate those decisions.

 

But ProjectVIEW provides the business reality against which those decisions must be tested.

 

The DANAOS ProjectVIEW AI Strategy

 

The strategy can ultimately be summarized in seven principles:

 

• Keep enterprise data governed.
• Keep ProjectVIEW ERP as the system of record.
• Structure project reality through BoQ, WBS and Cost Codes.
• Give AI only the business context required for the authorized task.
• Remain flexible regarding the underlying reasoning model.
• Use purpose-specific AI agents rather than disconnected generic AI tools.
• Keep consequential actions within enterprise workflows, permissions, approvals and audit trails.

 

That is the direction of ProjectVIEW AI.

 

• Not AI replacing the ERP.
• Not AI operating outside the ERP.
• Not ERP data being surrendered to AI.

 

But AI becoming an intelligent, governed participant inside the enterprise operating model.

 

ProjectVIEW provides the reality. AI provides the reasoning. Together, they create the intelligent project enterprise.

 

---

 

Frequently Asked Questions About ProjectVIEW AI

 

What is ProjectVIEW AI?

 

ProjectVIEW AI is the AI intelligence and agentic automation layer being developed around ProjectVIEW ERP. It applies AI reasoning to governed enterprise context derived from project processes, transactions and structured dimensions such as BoQ, WBS and Cost Codes.

 

Is ProjectVIEW AI a chatbot?

 

No. Conversational interaction can be one interface, but the broader strategy is purpose-specific AI agents capable of supporting analysis, recommendations and governed ERP workflows.

 

Does ProjectVIEW AI require companies to train their own Large Language Model?

 

Not necessarily. Enterprise data can be retrieved and supplied as controlled context to appropriate AI models without retraining a foundation model on the entire ERP database.

 

Is ERP data used to train public AI models?

 

The answer depends on the AI service and configuration being used. Enterprise services such as Microsoft’s models sold by Azure state that customer prompts and completions are not used to train generative foundation models without customer permission. Enterprise architecture and contractual terms should always be verified for the selected deployment.

 

Why is ProjectVIEW ERP important for construction AI?

 

Because AI needs structured operational context. ProjectVIEW connects project scope, schedule, cost, resources, procurement, subcontracting and actual execution through construction-specific business logic.

 

What is Agentic ERP?

 

Agentic ERP is an ERP architecture in which AI agents can observe enterprise information, investigate conditions, reason about potential actions and participate in controlled business workflows while remaining subject to permissions, approvals and audit requirements.

 

Can ProjectVIEW AI use different AI models?

 

Model flexibility is a core strategic principle: the enterprise business context and governance layer should remain stable even as underlying AI models evolve.

 

What industries can benefit from ProjectVIEW AI?

 

The architecture is particularly relevant to complex project-driven industries including construction, infrastructure, EPC/EPCI, marine and offshore construction, shipbuilding and ship repair, mining and quarrying, energy projects and project-based manufacturing.

 

---

 

About the Author

 

Christos Emmanouilidis is a Civil Engineer and Chief Customer and Commercial Officer at DANAOS Projects Software Solutions LLC

 

His work focuses on construction cost control, industry-specific ERP, project operations and digital transformation across project-based enterprises.