For many design firms, developing an artificial intelligence policy will be the easy part. The harder question is what happens after the policy is issued.
A document telling employees to use AI responsibly, protect confidential information, and verify the accuracy of AI-generated content may establish expectations, but it does not necessarily change how work is performed. For many firms, the real risk-management value comes from translating those expectations into controls that fit within the firm's existing project management and quality control processes.
It does not require creating an entirely new layer of bureaucracy. In most cases, the better approach is to incorporate AI into systems the firm already uses: project kickoff, contract review, QA/QC, technology approval, project documentation, and employee training. Here are a few practical places to start.
Start by Finding Out What Is Already Happening
Before adopting new controls, firm leadership should understand how employees are actually using AI. This does not need to be an exhaustive technology audit. A short discussion with discipline leaders, project managers, IT, and operations may identify most of the important uses. Ask what platforms employees are using and what they are using them for.
The answers may include meeting summaries, specifications, code research, calculations, design concepts, contract reviews, proposals, client correspondence, or internal administrative work. This exercise serves two purposes. First, it identifies areas where risk may already exist. Second, it prevents the firm from developing policies around hypothetical uses while overlooking what employees are doing every day.
For a larger multidisciplinary firm, it is also worth comparing practices between offices and disciplines. The firm's architects, civil engineers, structural engineers, marketing staff, and project managers may be using AI very differently.
The first management control is therefore relatively simple: Know what tools your people are using and what they are using them for.
Establish a Short List of Approved Tools
Employees should not have to determine on their own whether a particular AI platform is appropriate for project work. The firm should maintain a list of approved platforms and establish a process for evaluating new ones. That evaluation should look beyond the capabilities of the software.
The firm should understand how information entered into the system is stored, whether it may be used to train the provider's models, what security controls exist, and whether the platform is appropriate for confidential or proprietary information. This becomes particularly important where client contracts impose cybersecurity, confidentiality, or data-handling requirements. The objective is not to approve a particular AI application for every possible use. It is to give employees clear boundaries.
A project manager should be able to answer a basic question without calling IT, legal, and risk management: Can my team use this platform for this project? If that question is difficult to answer, the control probably needs improvement.
Classify AI Use Based on the Consequence of an Error
One of the most useful controls a firm can implement is also one of the simplest: stop treating every use of AI the same way.
An employee asking AI to improve the wording of an internal email does not create the same exposure as an engineer relying on AI to interpret a code requirement. Firms can address this through a basic three-level classification.
Low-risk uses might include brainstorming, formatting, generic administrative work, or nontechnical internal drafts.
Moderate-risk uses might include meeting summaries, research, specification support, contract summaries, proposal content, or certain client communications.
High-risk uses would generally include calculations, code interpretation, regulatory compliance, life-safety issues, technical design decisions, or information incorporated into professional deliverables.
The important distinction is not necessarily the technology being used. It is more about what happens if the information is wrong. As the consequence of an error increases, the level of independent professional review should increase with it. That gives employees a much more useful standard than simply telling them to "verify AI-generated information."
Put AI Into QA/QC Instead of Creating a Separate Process
Most established design firms already have quality control procedures. AI should become part of those procedures rather than sitting beside them.
If AI contributes to a technical decision, calculation, specification, code interpretation, or other material aspect of professional services, the existing QA/QC process should provide an opportunity to identify and verify that work. In higher-risk situations, the reviewer should be capable of independently evaluating the underlying issue rather than simply reviewing the AI-generated answer.
Having a second person read an AI response is not necessarily independent verification. The goal should be to determine whether the professional conclusion is correct based on reliable source information and professional judgment.
The question for firms should therefore become: Where in our existing workflow should this be checked? That makes AI governance part of project management rather than another administrative requirement.
Add AI to the Contract Review Checklist
Firms also need to recognize that AI risk may enter through the contract before it enters through the design process. Contract and RFP reviews should begin identifying requirements involving AI use, data privacy, confidentiality, intellectual property, cybersecurity, and third-party technology platforms. Particular attention should be given to provisions that require the design professional to guarantee the accuracy of AI-generated information or assume unusual responsibility simply because AI was used.
The preferable approach is generally to keep responsibility for AI-assisted services aligned with the normal professional standard of care. AI should remain a tool used in performing professional services, not a reason for the firm to assume a warranty of perfection. Project managers should also know when a client's requirements are more restrictive than the firm's general AI policy. An approved application may be appropriate for one project but prohibited under another contract.
Decide What Needs to Be Documented
Not every prompt needs to become part of the project file. That would quickly become impractical and would probably provide little risk management benefit. Documentation should instead be proportional to the significance of the AI use.
If AI helped improve the wording of a routine email, there may be little reason to separately document it. If AI materially influenced a technical decision, code interpretation, specification requirement, or other significant professional judgment, however, the firm should consider maintaining enough information to demonstrate that the result was independently evaluated. The goal is not to create an AI paper trail. It is to preserve evidence of professional judgment and appropriate review.
Establish an Escalation Process Before Someone Needs It
Employees should also know what to do when something goes wrong. What happens if someone accidentally uploads confidential client information to an unapproved platform? What happens if an AI-generated error makes its way into a deliverable? What if a project manager discovers that a subconsultant relied heavily on AI for technical work? Those questions should not be answered for the first time during an incident.
The firm should identify who receives AI-related questions and incidents, whether that is IT, risk management, general counsel, a technology committee, or some combination of those functions. The process does not need to be complicated. Employees simply need to know when to stop and who to call.
Start Small and Build the Controls Into the Firm
A firm does not need a 40-page AI governance manual to meaningfully reduce its risk. A reasonable starting point may consist of five things:
- An approved-tools list.
- A rule governing sensitive information.
- A simple risk-classification system.
- A requirement for independent review of higher-risk professional uses.
- And one person or group responsible for answering questions and updating the process.
From there, the firm can incorporate AI into project kickoff meetings, QA/QC procedures, PM training, and technology evaluations. The important part is that the controls reflect how employees actually work. AI governance is unlikely to succeed if it becomes another annual policy acknowledgment that employees click through and forget. The better measure is whether a project manager confronted with a new AI use can quickly answer three questions:
Are we allowed to do this?
What level of review does it require?
When do I need to escalate it?
If the firm can consistently answer those questions, it has moved beyond simply having an AI policy and begun actually managing the risk.