How to use AI in an architecture practice: from brief to permit
When people talk about AI for architects they almost always talk about images. But a project is a long chain: the brief, feasibility, regulations, design, documents, the estimate and the permit. This guide walks that chain stage by stage, tells apart the kinds of AI worth not confusing, and explains what each can do, what not to delegate and how to try it in your practice without changing the way you work.
In this article
The work nobody sees
Designing is the visible part of the job. Around it there is another one: finding which rules apply, checking that the drawings say the same as the report, redoing the area schedule every time a room changes, preparing the application and answering requests for information. It is necessary work, but it is not architecture, and it eats weeks.
Think of an ordinary week in a small practice with a change of use under way. On Monday the client asks whether the shop can become a home. On Tuesday the bylaw is found, it turns out the building sits in a protected area, and the heritage record is requested. On Wednesday the layout is drawn. On Thursday a bedroom changes, and with it the area schedule, ventilation, the accessibility form and the estimate. On Friday the permit documents are prepared, and someone finds a paragraph in the report about another project. Only Wednesday was architecture.
That is where AI adds most today, and also where it must be held to a higher standard: a render that could be better has no consequences; a misquoted requirement in an application does.
Three kinds of AI worth telling apart
Very different tools live under the same word, and each one is good for something different:
| Type | What it is good for | Where it fails |
|---|---|---|
| Image generation | Exploring atmospheres, materials and variations from a sketch or a model. Communicating an idea to the client. | It knows nothing about regulations or dimensions. A convincing image can describe an impossible building. |
| General-purpose language models | Drafting, summarising, organising ideas, explaining a concept or a rule in plain language. | They answer confidently even when they do not know. They can cite articles that do not exist or repealed versions. |
| Specialised tools with sources | Reading the project’s documents and the rules that apply, cross-checking them and saying where each figure comes from. | They only know what they have loaded. A good one says what it does not cover; a bad one hides it. |
For a practice’s technical work, what matters is the third: that the answer rests on the rules in force and the project’s data, and that you can check it. An answer without a source is no use in an application, however good it sounds.
Stage by stage
| Stage | What AI can already do | What remains yours |
|---|---|---|
| Brief and feasibility | Understand a brief written in your own words, identify the type of work, the use and the town, and say what must be checked before you start drawing. | Deciding whether the commission is viable and how to approach it. |
| Regulations | Gather the rules that apply, from national codes to the local bylaw and heritage protection, with the article, source and version of each requirement. | Interpreting borderline cases and the council’s criteria. |
| Design | Images and variations from your model; comparing options with their areas, uses and parameters. | The design. |
| Documents | Read drawings and report, cross-check their schedules, find contradictions and missing sections, and prepare drafts with the project’s data. | Describing and justifying the solutions. Signing. |
| Quantities and estimate | Read the estimate and the BC3 file, check that chapters add up and match the report. | Prices and the judgement behind each item. |
| Permit | Check that the application is complete before submitting it and organise the points of a request for information with what the documents say. | The relationship with the planning officer. |
| Team | Keep everyone on the same version and show which documents change when a figure changes. | Running the practice your way. |
Brief and feasibility
This is the stage where a mistake costs most, because everything else is built on top of it. Before drawing you need to know what the plan says about the plot, whether the use is permitted, whether there is heritage protection or sector constraints, and which permit procedure applies. A useful tool asks these questions for you from the address and the brief, and returns a list of what is confirmed and what is still to be checked. In a retail to residential change of use, for instance, whether the use is permitted decides whether there is a project at all.
Regulations
The rules for a project in Spain stack in layers: the national building code and laws, regional rules on accessibility, housing or business activities, the local plan and municipal bylaws, and sometimes a heritage list. Each layer has its own version and date. What AI contributes is not knowing everything, but gathering what applies to this project and saying where it comes from.
An example of what «checking» means: whether a stair complies depends on the building’s use and on how many people use it, and it is governed at once by the fire document (evacuation) and the safety-in-use document (falls). A useful tool does not give a generic figure: it gives the one that applies to that project, with the section of each rule.
Design
Here AI helps you explore, not decide: façade variations, materials, atmospheres, sun studies. The most useful part is not the image but that each option comes with its numbers — area, floor area used, use — so options are compared on judgement and not just by eye.
Documents
This is where most time is saved. The report, drawings, forms and estimate repeat the same figures, and every change means updating them all. A tool that reads the documents finds what does not match, the missing sections and the paragraphs that come from another project. We cover it in detail in what a project report must contain under Spain’s building code.
Quantities and estimate
The estimate usually lives in another program and another format (the BC3 files of Presto and similar tools). Reading it alongside the rest lets you check what slips through: that chapters add up, that there are waste and safety chapters, that the items describe the same envelope as the report. Prices and the judgement behind each item remain the practice’s.
Permit and requests for information
Before submitting: checking the application has everything that council asks for. Afterwards: when a request for information arrives, organising each point with the document and page that answers it, and what is still to be done. It is cross-checking work that AI does well and that saves back-and-forth.
What not to delegate
Interpretation and responsibility. Some requirements depend on the planning officer’s judgement, on alternative solutions or on what counts as the main use. A good tool says so instead of inventing it, separates what it has checked from what it has not loaded, and leaves the signature where it belongs: with the qualified professional.
Nor the relationship with the client or design decisions. AI can prepare the comparison between two options; choosing between them, and explaining it to the client, is the craft.
Risks and how to manage them
- Invented answers. Require every requirement to come with its article and source, and distrust any that does not. Check the first answers against the rules until you know how the tool behaves.
- Outdated regulations. Ask which version of each rule it uses and how it is updated. A correct requirement from a repealed version is still a mistake.
- Confidentiality. Your clients’ projects are sensitive information. Find out where documents are read and stored, who can see them and whether they are used for anything other than your work.
- Lock-in. Make sure the tool works with your formats and lets you take your data out. If you leave tomorrow, your projects must still be yours.
- Cost. Understand how it is charged — per user, per project or per use — before bringing in the whole practice.
How to start without changing the way you work
- Start with a real project, ideally one already submitted: that way you know what the tool should find, because you have the request for information that came back.
- Start with the review before submission, where a mistake costs most and where its value is easiest to measure.
- Check what it does with your documents: where they are read, where they are stored and who sees them.
- Keep your organisation: folders, names and software. AI should adapt to the practice, not the other way round.
A sensible pilot lasts a month. Week one, a project already submitted: compare what it finds with the actual request for information. Week two, a project in progress, review only. Week three, the regulations for a new commission. Week four, decide on what you have seen: which tasks it saves you, which it does not, and what it costs.
How to choose a tool
| Question | Why it matters |
|---|---|
| Does it cite the article, official source and version of each requirement? | Without a source you can neither check it nor defend it to the council. |
| Does it know your region’s rules and your town’s planning? | Most requests for information come from regional rules and bylaws, not the national code. |
| Does it say clearly what it does not check? | The danger is not what it does not know, but not saying so. |
| Does it read your documents as they are? | PDF, DWG, BC3. If you have to redo them for it to understand, it saves no time. |
| Where do your projects end up? | Confidentiality with your clients and control over your data. |
They are the questions we build Archelo around. Our page on AI for architects explains what it does today and what it does not.
