In civil engineering, data carries significant weight. Many files, drawings, reports, and contracts carry some form of protection, either for the engineering firm to ensure proprietary information and processes are not shared, or for the client to ensure that vital content is protected. This is not just in terms of project performance, but in terms of legal liability, client trust, and regulatory compliance.

As AI tools become more common, from ChatGPT to custom language models, engineers are more inclined to plug in documentation and start asking questions due to the ease of use, time savings, and overall boosted efficiency. However, the truth is, not all AI tools are safe for these protected documents, and many are not compliant with the rules you’re required to follow.

This week, we’re diving into one of the most important and least understood parts of engineering automation: data security and regulation. Whether you’re a junior engineer experimenting with automation, or a firm principal thinking about rolling out AI tools, you need to read this.

Security Isn’t Just a Feature — It’s a Legal Obligation

Civil Engineering is a highly regulated industry full of building codes, ethical regulations, unique project contracts, and many dos and don’ts that must be well understood. You work on bridges. Roads. Hospitals. Public housing. Pipelines. The data you handle is often confidential and sensitive in these situations.

Many of the firms we talk to say things like:

• “We’d love to use AI, but our projects are under NDA.”
• “We have municipal contracts — we can’t risk leaking anything.”
• “We don’t know the security of these new applications so we do not want to risk using them, even if they can help us.”
  

These concerns are understandable and valid, because feeding sensitive engineering data into ChatGPT or a third-party AI tool can breach data compliance, expose client IP, and violate professional codes of conduct — especially if you don’t know where that data ends up. But as we move forward with AI, it will become ever more important to incorporate them into workflows. We are already past the innovators and early adopters and are moving to the early majority in terms of the Innovation Adoption Lifecycle Curve.

How Most AI Tools Actually Work (And Why It Matters)

This is the part no one talks about in marketing brochures. The majority of AI tools you see today, including the ones used by startups, point solutions, and even internal apps, don’t have their own language models. They don’t build their own GPTs or LLMs from scratch. Instead, they use OpenAI’s API, Anthropic, Grok, Gemini, or similar providers under the hood and fine-tune them as needed. This is totally fine — if they’re doing it right.

Doing it right means:

• They use secured API keys instead of public-facing inputs.
• They disable data logging and model training (OpenAI allows this for API-based usage).
• They isolate customer data and avoid multi-tenant leakage.
• They store nothing permanently without explicit permissions.

However, if you copy-paste your client’s structural design or contract scope into ChatGPT without having an enterprise license or following the proper procedures, that data can be used to improve the model because you agreed to it in the terms of service.

Custom API Keys vs. Public Models

Let’s break this down in plain terms.

Often logs prompts by default	Uses custom API keys to authenticate securely
May train on inputs unless you opt out	Ensures data stays private and never trains the model
Not allowed under most engineering NDAs	Can be deployed within controlled environments (AWS, Azure, on-prem)
Not secure for PII, design data, or proprietary specs	Offers logging, access control, and compliance management

These are the main differences between private and public, and all this information can be found by asking providers. At Sidian, we ensure client’s security needs are met by making secure solutions internally and deeply understanding what the companies we work with have going on under the hood.

Regulations You’re Probably Bound By

If you’re working in Canada, the U.S., or abroad, your work likely falls under one or more of the following:

Canada

• PIPEDA (Personal Information Protection and Electronic Documents Act)
• Provincial laws (e.g., Ontario’s FIPPA for public institutions)
• EGBC and PEO guidelines regarding confidentiality, digital signatures, and public trust

United States

• CISA guidelines for critical infrastructure
• FERPA, HIPAA, or ITAR for certain contracts
• State-level legislation on consumer data (e.g., CCPA in California)

Global Projects

• GDPR (EU) — extremely strict on personal and identifiable data
• Data Localization laws (India, China)
• Project-specific NDAs for government, military, or infrastructure projects

Even if your head office is in one country, if your project crosses borders — even a single client in Europe — your tool must follow the laws of that country too. There are other requirements as well, but this gives some flavor into the landscape.

Data Pipelines, Warehouses, and Lakehouses

Many vendors throw around terms like “pipelines,” “warehouses,” and “data lakes” like they’re interchangeable. They’re not. If you’re building internal tools, working with AI, or choosing vendors, this distinction matters.

Data Pipeline

A system or workflow that moves and processes data from one system to another — for example, from your engineering logs or field notes to an AI model for analysis.

Think of it as the plumbing: it extracts, transforms, and loads data (ETL).

Examples: Moving PDF reports to a vector database or exporting Excel sheets to a dashboard.

Risk: Poorly built pipelines can cause data leakage, corruption, or model drift.

Data Warehouse

A structured database designed for analysis of clean, tabular data (like spreadsheets or SQL tables). It’s built for fast queries, dashboards, and business reporting.

Best for historical data, KPIs, and compliance tracking.

Pro: Great for dashboards, finance, and operations.

Con: Not meant for messy or unstructured data like images, drawings, or sensor logs.

Data Lake / Lakehouse

A data lake stores raw, unstructured, or semi-structured data — everything from CAD drawings and sensor data to PDFs and emails.

It’s cheaper and more flexible than a warehouse but requires more governance.

Pro: Ideal for machine learning, AI development, and multimodal data.

Con: Without structure, data lakes can become disorganized “data swamps.”

Final Thought

For AI to be effective — and safe — your data must be centralized, retrievable, inspectable, and secure. Choosing the right storage model matters. Otherwise, you’re building your AI systems on quicksand that is bound to fail. On average, 80% of AI systems do not meet their intended purpose and a large reason for this is unstructured/inadequate data.

What This Means for Civil Engineering Firms

Whether you’re a boutique shop or a 500-person consultancy, these are your core responsibilities when exploring AI:

Core Responsibilities

1. Don’t use public LLM tools for client data.
   Unless explicitly approved, that means no ChatGPT, no Copilot in Outlook, and no Slack plug-ins with default settings.
2. Use custom API-based tools with data logging disabled.
   This is how Sidian and the pros stay compliant.
3. Store your data in governed, searchable formats.
   If your data’s a mess, AI will struggle to help you and provide an ROI.
4. Document everything.
   If it can’t be audited, it can’t be trusted.
5. Match the regulations of every country you work in.
   This is critical…especially for international projects.

The Future Is Smart, But It Must Be Safe

Civil engineering is transforming. However, that transformation will only succeed if it’s done with rigor, responsibility, and respect for the data we hold.

Your models, your drawings, your RFIs — they’re not just files. They’re the foundation of physical infrastructure, and they deserve to be protected with the same seriousness as the structures they represent.

At Sidian, we’re building AI systems that aren’t just smart — they’re safe and we ensure all providers we work with meet the needs of our clients in this realm. Wrapped in encryption. Built with compliance in mind. Auditable, transparent, and professional grade. Because in our world, trust is earned, and one data breach is all it takes to lose it.

Let’s build responsibly. Let’s build the future.