AI shows up in five places on an airport capital program: early planning and capacity analysis, concept design and site studies, document review before permit and bid, construction progress capture and schedule risk, and terminal operations after opening. The maturity differs sharply by stage. Progress capture and document review are in routine production use; generative site design and schedule prediction are still being proven on real programs; anything touching airfield safety, security screening, or FAA approval stays with the responsible engineers, the airport operator, and the agency. Nothing on this list approves a design or shortens an FAA review.
Why airport programs break ordinary tools
Four things make an airport different from a building of the same value:
- Scale and packaging. A terminal program is issued as many packages, by several design teams, over several years. Enabling works, airside civil, terminal core and shell, fit-out, baggage handling, and systems each arrive on their own schedule with their own drawing set.
- Interfaces everywhere. Apron paving meets terminal structure, baggage handling meets the building it runs through, screening equipment meets both the architecture and the security concept. The seams between packages are where the money is lost.
- A live operation. Work is phased around flight schedules, and temporary conditions are designed work in their own right, with their own drawings that also have to be coordinated.
- A reference stack that is not the building code alone. FAA advisory circulars, airport design standards, security requirements, airline and operator criteria, and the owner's own standards all sit on top of the applicable building and fire codes, and aircraft hangars carry their own fire protection standard (see the NFPA 409 hangar guide).
Any tool that assumes one design team, one set, and one delivery date is going to disappoint on this work.
Where AI fits, stage by stage
| Stage | What AI is used for | How mature it is | What stays human |
|---|---|---|---|
| Planning and capacity | Passenger flow and capacity simulation, demand forecasting, gate and stand allocation studies | Simulation is long established; machine learning on top of it is newer and only as good as the operational data behind it | The planning assumptions, the growth case, and the decision to build |
| Concept and site design | Generative massing and site option studies, environmental and daylight analysis, rendering and visualization | Useful for exploring options early; output is a study, not a design | The design itself, and every engineering judgment inside it |
| Document review before permit and bid | Reading a complete set and cross-checking drawings against each other, against specifications and reports, against owner and FAA references, and against the building codes that apply | In routine production use, and the stage where the work is most tractable: every check is a comparison between documents | Which document governs, whether a finding is real, and what the correction is |
| Construction and progress | 360-degree photo capture matched to the plan, progress tracking against schedule, schedule risk models, safety observation review | Photo capture and progress comparison are mature; schedule prediction is improving and still needs a human read | Acceptance of work, schedule recovery decisions, safety enforcement |
| Operations after opening | Turnaround and stand monitoring, baggage flow, predictive maintenance, passenger flow management | In service at many airports, generally as operator tools rather than project tools | Airfield safety, security decisions, and irregular operations |
Read down the maturity column before budgeting. Two of these five stages have tools a program can rely on today; the rest are worth piloting with a clear question and a way to tell whether the answer was right.
The document-review stage in detail
This is the stage with the clearest return, because the work is bounded: take an element on one sheet and find every other place it is described. On an airport set that means following the apron elevation into the terminal finished floor, the baggage conveyor route into the structure above it, the screening lane count into the equipment schedule, the utility corridor into the civil package issued eighteen months earlier.
The scale is the reason it needs software. A reviewer can hold one package in mind. Nobody holds nine. A document review that reads every uploaded sheet finds the package-to-package mismatches that a sampled review cannot, and it can be run again on the next issue without the cost of the first pass.
What matters when choosing a tool for this stage:
- No cap on set size. Airport packages run to thousands of sheets. A per-project price that assumes a hundred-page building set does not work here.
- References, not just drawings. The review has to accept the specifications, geotechnical and other reports, owner standards, and the FAA advisory circulars and security guidance you consider governing, and check the drawings against them.
- Evidence on both sides. A finding that names two packages is only actionable if it shows the sheet and the words on each side.
- Archive sets. Existing-conditions drawings on a live airport are often decades-old scans. The review has to read scanned and hand-drawn sheets, not only native exports.
Groundbook AI works at this stage: it reads terminal, airside, landside, baggage, security, civil, and building-system documents together with the government-published codes it reads online and the references you upload, and returns potential conflicts with the sheet behind each one. It does not plan capacity, generate designs, monitor construction, or run operations.
Review the airport set as one package
Check every discipline in the terminal set together. Groundbook flags potential conflicts with links to the source sheets.
Handling FAA and owner references
The reference stack is the part teams most often get wrong when they bring a general-purpose tool onto an airport program. A review is only as good as the documents it was given, and no tool should be assumed to know which advisory circular edition, security guidance, or airport standard applies to your project.
Name them explicitly. Groundbook reads the FAA advisory circulars and the building and fire codes that governments publish online, and uses licensed codes and standards only where a license allows it. Upload the airport's own design standards, the operator and airline criteria, and any other reference the review needs, including a licensed code where your license allows it, and say in the review instructions which ones govern where they conflict. Then the findings cite a source your team can check, instead of a general claim about what airports require.
Confirm applicability with the responsible engineer and the agency. An AI finding that cites an advisory circular is a question worth investigating, not a determination that the design is non-compliant.
What AI does not decide on an airport program
Say this plainly to any stakeholder who asks:
- It does not approve a design, issue a permit, or shorten an FAA review.
- It does not make airfield safety, security, or irregular-operations decisions.
- It does not establish which of two conflicting documents governs. That is a document-control decision for the program.
- It does not replace the engineer of record, the airport's technical review, or the authority having jurisdiction.
What it does is widen coverage. On a program where nobody can read every sheet of every package, a tool that reads all of them and reports the disagreements changes what the review team spends its hours on.