Amid walls lined with 3D-printed miniature buildings and framed graphics of design features, we meet Dr Gabriel Wurzer at TU Wien’s Institute of Architectural Sciences. He leads the Center for AI in Architecture, Planning, and Environment (AI|APE) and has a background in software development for the Research Unit of Digital Architecture and Planning. We get to talk about novel collaborative planning methods, discussing software intricacies, clashing data cultures between research and practice, pedestrian simulations and resistance against AI in design.

Collaboration through Building Information Models (BIM) 

“It's a very common problem in the Architecture-Engineering-Construction (AEC) sector that the planning teams don't understand or even hinder each other because one team needs something on which another team builds. These circular dependencies between collaborating disciplines turn every building project also into a data problem. Previously, we used to draw floor plans and sections by hand or using CAD programs. But nowadays we have a method called Building Information Model (BIM) to work together.”

Gabriel Wurzer explains BIM as a way to enable simultaneous work by representing a building in hierarchical groupings: a tree structure with the whole building at the top, followed by floors, then walls, doors, and other components, each enriched with properties such as thickness or structural data. From this rich model, architects still generate familiar outputs: floor plans and spreadsheets listing all parts that need to be ordered. The software solutions ArchiCAD and Revit dominate this ecosystem and lock users into expensive licences, proprietary file formats, and their own built-in versioning systems. Though some project files can be exported into other formats, Gabriel Wurzer notes that existing standards do not clearly prescribe what information must be filled in at which project stage. This is why most BIM managers enforce project-specific “house rules” for data entry themselves, but there is no widely accepted, uniform process model, making data sharing in architecture more difficult.

Interoperability does not equal FAIR

“Interoperability of formats is achieved by staying locked inside one software family. The problem is that interoperability doesn’t equal FAIR. Data stays unavailable because everyone wants to keep it secret from competition, or NDAs are in place. Architects focus on showcasing designs, not necessarily making data public. Data in itself is just an empty hull, an empty package. It means nothing for architects without purpose. Only through concrete applications, such as analyses in a BIM context, does it become meaningfully usable.”

Gabriel Wurzer draws a sharp line between research and practice at the Institute of Architectural Sciences. While research embraces more openness – albeit with limits on code and data sharing – practice guards everything fiercely, and sharing rarely goes beyond PDFs submitted for municipal approval, such as evacuation plans. Competition fears dominate: why share rich BIM data when others could copy elaborate designs without anyone paying? According to Dr Wurzer, data in Architecture is often only substantial in the context of a BIM, which gives it meaning through clash detection between different building parts, bills of materials, or other advanced methods of analysis, for example, in structural engineering. While some open BIM databases exist, most data remain siloed within projects, and even design-based research, like in his case, simulations for hospital planning, builds on scientific outputs as case studies, not design methods or raw data. 

Working with simulations for hospital planning 

“Because so little data is openly available, planning-related research has to rely on other means. Hospitals are often designed on the basis of data that is already ten years old—in a planning process that itself takes another ten years. As a result, there is a very real risk that such buildings are already outdated by the time they open. To counter this, planning is increasingly no longer understood as static, but rather in relation to the changing demand for healthcare services in a society that is itself undergoing transformation. One concrete method used in this context is the simulation of processes. Put simply, this allows one to observe how patients move back and forth between different stations, consume medical services, and require staff resources. All of this is done in order to more precisely determine and justify partial aspects such as the size of waiting areas. It also allows the spatial requirements of facilities to be estimated more accurately, even under changing socio-demographic conditions.”

Dr Wurzer works on simulations for the new hospital building in Wiener Neustadt, using pedestrian flow models and custom-built toolchains — from NetLogo to Python and JavaScript. To avoid the need of constant refurbishment in hospitals outgrowing their capacities, simulations help architects check basic questions they can’t easily answer: How many people fit into the design? Where queues form, and when corridors become too dense. A self-written flow editor divides traffic between departments and tracks how abstract movement turns into physical flow — beds, waiting areas, bottlenecks. Dr Wurzer writes most of the code himself: “We’re doing a project, not a product,” he says. The software can be rough around the edges because it’s built for research, not for sale or necessary repurposing. Simulation models get mostly rebuilt from scratch each time to fit the next question. This is also why, in contrast to software developers, architects generally don’t have or have little incentive to share on platforms like Git or Zenodo. Because such openly accessible datasets and well-documented methods are lacking, it becomes difficult to develop AI models for planning tasks; researchers often have to rely on scattered sources or painstakingly build the necessary data foundations from scratch. 

Data bunkers to slow down AI

“Previously, computer science and automation were often marginalised within architecture – automation was something associated with the “odd” colleague who wrote a script so others no longer had to draw fire extinguishers by hand. Today, the situation risks reversing: instead of automation being peripheral, architects themselves may become marginalised as providers of knowledge for AI systems developed elsewhere. Architects will likely try to resist this by protecting their data and expertise – creating “data bunkers” of sorts. They will readily adopt tools that make their work easier, but they are unlikely to accept a situation in which their knowledge primarily serves to train other people’s AI.”

According to Dr Wurzer, AI is revolutionising architecture by automating tedious tasks like upscaling or colouring visualisations, massing studies, and even early urban planning, freeing designers from grunt work while informing decisions at unprecedented scales. For example, reverse-engineer specific building plans to train an AI on how these types of structures work, then generate new designs from them. Tools like Autodesk Forma (formerly Spacemaker) or Infrared City let users generate entire building blocks, factoring in climate change effects such as rising temperatures, solar radiation, and energy-efficient massing to achieve net-zero goals, et cetera. 

Gabriel Wurzer is concerned that resistances run deep and not without cause. Architects tend to hoard data in what he calls “bunkers,” reluctant to share plans for AI training – fearing competitors could reverse-engineer and replicate their signature styles without cost. Design itself remains human territory: iterative, grappling with incomplete real-world data where no solution ever fully addresses every problem. Research often chases solutions-first – generating a wild form, then figuring out buildability – but practice prioritises proprietary edges over open collaboration.

Contact

Gabriel Wurzer 
Research Unit of Digital Architecture and Planning 
TU Wien
gabriel.wurzer@tuwien.ac.at

Center for Research Data Management
TU Wien
research.data@tuwien.ac.at