Practice Resources · R4
Studio Policy Starter
The AIA's guidance tells architects to keep human oversight and remain the professional of record. It is silent on client disclosure, on confidentiality of project data, and on what a firm should actually write down. This is an attempt at the missing document.
Independent and personal
This document is my own work and my own opinion, written in my own time. It is not issued by, endorsed by, reviewed by, or connected to my employer. It does not describe, quote, or draw on any firm's internal policy, and nothing in it should be read as representing HOK, its practices, or its clients. Everything on this site is written the same way.
Seventeen clauses · Seven sections · Free to adapt
Download the PDF ↓Before you use it
This is a starting point for a conversation with your own counsel and insurer, not legal advice, and not a substitute for either. I am an architect, not a lawyer. Contract terms, professional liability policies, and state regulations vary, and any of them can override what follows.
How to use it
- 01Read it once and mark what is wrong for your practice. Roughly a third of it will be.
- 02Cut anything you will not actually enforce. A policy with three clauses everyone follows beats a policy with twenty that nobody has read.
- 03Take sections 2 and 3 to your counsel and your insurer before you adopt them. Those are the two that touch obligations you already have.
- 04Put a name against every clause that says "a named person." Unassigned responsibility is the most common failure in documents like this.
- 05Date it, issue it, and diary the six-month review before you close the file.
Scope
- 1.1
This policy applies to any tool that generates, summarizes, translates, evaluates, or otherwise processes project content using machine learning, whether purchased for that purpose or included as a feature of software the firm already uses.
Why
The obvious chatbot is not the problem. The problem is the assistant quietly added to software you licensed three years ago, which nobody registered as a decision. Write the policy around the behavior, not the brand, or it is out of date the week you issue it.
- 1.2
This policy applies to everyone working on the firm's projects, including consultants and contract staff, and applies on personal devices and accounts as it does on the firm's.
Why
The gap most policies leave is the person using their own account on their own laptop at home on a Sunday. Naming it is uncomfortable and necessary.
Confidentiality and client data
This is the section that will matter first, and the one most likely to be tested before anyone has thought about it.
- 2.1
Do not enter client-identifying information, confidential project material, drawings, program documents, budgets, or correspondence into any tool that has not been approved by the firm for that purpose.
- 2.2
Before a tool is approved, a named person must confirm in writing what the vendor does with submitted content: whether it is retained, for how long, whether it is reviewed by humans, and whether it is used to train models.
Why
Ask for it in writing and keep the answer. Vendor terms change, and the version you agreed to is the one you can point at later.
- 2.3
Where a client agreement or non-disclosure agreement restricts disclosure of project information to third parties, an unapproved tool is a third party.
Why
The clause people miss, and the one an attorney will reach for first. Most NDAs in force today predate these tools and say nothing about them, which is not the same as permitting them. Pasting a program document into an unapproved service is a disclosure. Whether it is a breach depends on the agreement, but the burden of being sure sits with you.
At scale
Sole practitioner: one page listing approved tools and what may go into each is enough. Fifty and up: this belongs to legal and IT, and the design-side job is to make sure the approved list is usable enough that people do not route around it.
- 2.4
Where a project carries heightened confidentiality obligations, including government, healthcare, defense, or data center work, no tool may be used on that project without specific written approval for that project.
Why
Blanket firm approval is not project approval. Some clients have their own requirements that are stricter than yours and are not negotiable.
Authorship, review, and responsibility
- 3.1
The architect of record is responsible for every document the firm issues, regardless of how any part of it was produced. No tool holds a license, and no tool carries responsibility.
Why
State this first and plainly, because it settles most of the anxious questions before they are asked. Nothing about these tools changes who is accountable to the public.
- 3.2
Nothing leaves the office without review by a person competent to have produced it unaided.
Why
The load-bearing phrase is "competent to have produced it unaided." Review by someone who could not have done the work themselves is not review; it is a signature. This is also the clause that quietly protects your junior staff, because it says the firm still expects them to learn how to do the thing.
- 3.3
These tools do not perform code analysis, structural or life-safety calculation, specification writing, or any other work that a licensed or otherwise qualified professional is required to perform. Output on those subjects is a prompt for a professional to check, never a result.
Why
Worth writing down even though it seems obvious. Confident, well-formatted, wrong code analysis is the single most plausible way one of these tools puts a firm in front of a board.
- 3.4
Where a deliverable was substantially assisted by these tools, the reviewer records that in the project file.
Why
Not to create a paper trail against yourself. Because in two years, when someone asks how a decision was reached, you want the record to exist and to be boring.
Client disclosure
The AIA has not taken a position here, so the profession is writing this norm right now, one firm at a time. Deciding deliberately beats improvising when a client asks.
- 4.1
The firm answers questions about its use of these tools honestly and specifically. Nobody is instructed to be vague.
Why
The question clients actually ask is rarely "did you use AI?" It is "who is accountable for this?" Answer the second one clearly and the first usually resolves itself.
- 4.2
The firm discloses proactively where the client's agreement requires it, where a client has expressed a preference, or where the output is itself the deliverable rather than a step toward one.
Why
A summary you wrote from a machine-assisted first draft is a step. A rendering the client will publish, or a narrative report presented as the firm's analysis, is the deliverable. The distinction is doing real work in that sentence and is worth arguing about internally before you need it.
- 4.3
Generated imagery is never presented as a photograph, as a record of an existing condition, or as a depiction of a real place the firm has not verified.
Why
This will look prescient in about three years. Once a synthetic image enters a public record or an entitlement submission as though it were evidence, the problem stops being reputational.
What these tools are for
Any list of approved uses will age. The principle underneath it should not: the tool may shorten the distance to a decision. It may not make the decision.
- 5.1
Ordinarily appropriate, subject to review: research and retrieval, first-pass checks against requirements, coordination and clash review, restructuring or summarizing text the firm already owns, generating options for internal study, and drafting internal correspondence.
- 5.2
Not appropriate without specific written approval: anything issued for permit or construction, sealed documents, client-facing analysis presented as the firm's own, statements of professional opinion, and any personnel or hiring decision.
Why
The personnel line does not belong to design practice and is here anyway, because it is where a small firm is most likely to create a legal problem without noticing.
- 5.3
Design intent is authored by a named person who is accountable for it. Tools may inform that judgment and may argue with it. They do not hold it.
Why
If you keep one clause from this document, keep this one. Everything else is administration. This is the profession.
Approving a tool
- 6.1
One named person maintains the list of approved tools and the conditions attached to each. The list is available to everyone and dated.
At scale
Sole practitioner: that person is you, and the list is a note in your project template. Two hundred people: it is a maintained page, and it fails the moment it is not.
- 6.2
Approving a new tool means recording four things: what happens to data put into it, what rights the firm holds in the output, what it costs, and who is accountable when its output is wrong.
Why
The fourth question is the one vendors do not answer and the one that decides whether you should adopt it.
- 6.3
A tool that changes its terms is not automatically still approved.
Keeping this current
- 7.1
This policy is reviewed every six months, and the date of the last review appears on its face.
Why
A policy nobody revisits becomes a liability of its own, because it documents a standard the firm has stopped meeting. An out-of-date policy is worse evidence than no policy.
- 7.2
Anyone in the practice may propose a change, and proposals are answered rather than filed.
Why
The people who find the gaps are the ones using the tools at eleven at night, and they will only tell you once if nothing happens the first time.
Version 1.0 · Updated August 2026
Download the PDF ↓Free to adapt, in whole or in part, with or without credit. If you improve it, I would like to see what you changed.
Send corrections and disagreements to hello@frankcauthen.com. The reasoning behind clause 5.3 is worked out at length in The Tighter Loop and argued against in Judd’s Objection.