How engineering firms can explain data use to clients

What should an engineering firm tell clients about data use?#

An engineering firm should tell clients four things about data use: which record types are involved, whether that client's projects are included, in what form, and who approved the release. Clients rarely object to the idea in the abstract. They object to surprises, vague answers and the sense that their drawings left the building without anyone asking.

The records that interest AI developers are mostly the firm's own working history: RFI responses, submittal review comments, internal QA checks, design review notes, scope changes and the reasoning behind them. Stamped drawings, client-furnished surveys and site security details are a different category, and saying so early takes most of the heat out of the conversation.

Data is licensed, not sold outright. The firm keeps ownership, and the license limits how the buyer may use the records. That distinction is worth stating in plain words, because many clients hear 'selling data' and picture their project files posted somewhere.

Decide the client's scenario before the conversation#

The client's scenario should be settled internally before a principal calls anyone. Three scenarios cover almost every client relationship, and each leads to a different conversation, a different entry in the project file and a different amount of effort.

Contract terms decide the scenario first and the relationship second. An agreement with a broad confidentiality clause, a no-AI-use clause or client ownership of all project documents points toward exclusion or consent. An agreement that is silent on the firm's internal work product may allow de-identified inclusion, subject to the rights review and counsel's reading.

Which client questions come first, and how to answer them#

Client questions about data use cluster around a few worries, and a prepared answer for each keeps the conversation short. Project managers should hear these answers too, because clients often ask the person they meet every week rather than the principal.

Scenario one: the excluded client#

An excluded-client conversation is the shortest of the three and often the most useful for trust. The message is that the firm has reviewed its agreements, that this client's projects will not be part of any data license, and that the firm is telling them so they hear it first.

Exclusion makes sense for utilities and critical infrastructure owners, clients with security-sensitive facilities, projects under claims or litigation, and any client whose agreement gives it ownership or control of all project documents. Excluding a client often costs less than it first appears, because the firm's QA procedures, templates and general methods can still be reviewed separately.

Tag exclusions at the client level, not the project level, so a new project for the same client inherits the flag automatically in Deltek, BQE Core or whichever system holds the project list.

Scenario two: de-identified inclusion#

De-identified inclusion means the client's projects contribute internal working records after identifying details are removed, so the conversation centers on what removal covers. Some firms notify these clients even when the contract does not require it, because a short letter now is easier than a difficult call later.

For engineering records, identifying details go well beyond names. Title blocks, seals, sheet borders, project numbers, permit and parcel numbers, coordinates, street names in drawing notes and photographs of recognizable sites all carry identity. RFI and submittal logs often name the contractor, the owner's representative and the building official.

Explain that automated tools do part of the work and people check the rest. Presidio, an open-source de-identification toolkit, states in its own documentation that automated detection cannot guarantee finding all sensitive information and that additional protections should be used. That is an honest point to share with a client who asks how removal is verified.

Scenario three: consent-based inclusion#

Consent-based inclusion applies when the firm wants records the client has a say over, and it starts with a written request rather than a phone call alone. A specific request is easier for the client's counsel to approve than an open-ended one.

Keep the request free of hype and free of any figure about what the records might be worth. Value is known only once a buyer engages, and a client who sees a number tends to ask for a share of it before reading the rest.

• 1Record types requested, named concretely: RFI log with responses, submittal review comments, design review notes, change documentation.
• 2Projects covered, by name or date range.
• 3Form of release: de-identified, with the categories of detail removed.
• 4Purpose and permitted use in the license's terms, and confirmation that the firm keeps ownership.
• 5What stays out entirely, such as drawings, models, site security information and client-furnished documents.
• 6The client's approval point and how to withdraw consent before release.
• 7A named contact at the firm for questions.

Illustrative: a civil and structural firm sorts its client list#

Illustrative: a fictional civil and structural engineering firm with three offices keeps projects in Deltek Vantagepoint, RFIs and submittals in Procore, and review markups in Bluebeam. Before anyone is contacted, the managing principal asks the contracts manager to sort active and recent clients into the three scenarios.

A regional water utility lands in the excluded group because its agreement treats all project information as confidential and its sites are security-sensitive. Most private developers fall into de-identified inclusion, and each receives a short notice letter listing the internal record types. One manufacturing client's agreement gives it control of all project documents, so the firm sends a consent request covering RFI responses and design review notes only. The client approves on condition that process equipment layouts stay out, and the firm records that condition against every affected project.

How SourceX approaches client communication#

SourceX treats client communication as part of the Rights step in the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. Each client's scenario is settled during the rights review, before preparation starts, and the firm approves every step.

The decisions are documented in the SourceX Evidence Packet, which records provenance, licensing rights, permitted use, the privacy record and release authorization. A consent letter or exclusion flag becomes part of that record, so the firm can show any client exactly what was decided and why.