How Aphex Uses AI

Our Approach to AI

At Aphex, we see AI as a tool that can be embedded within core workflows to help construction teams plan, communicate, coordinate, and track their work more effectively. Rather than building standalone AI features, we focus on solving specific user problems where AI provides the best path to a solution.

We always start with identifying genuine user problems. When we find that AI offers the most effective way to solve them, we explore that path thoughtfully and transparently.

We apply the same discipline to how AI handles your data as we do to the product itself. The principle is simple: using Aphex's AI features should not introduce new vendors with access to your project data.

Where Your Data Goes When You Use Aphex AI

This is usually the first question IT and information security teams ask, so we'll answer it directly.

Aphex is built and hosted on Google Cloud Platform (GCP). Our AI features run inside that same environment. All large language model processing — whether using Google's Gemini models or Anthropic's Claude models — happens through Vertex AI, Google Cloud's managed AI platform, within Google's infrastructure.

A deliberate architecture choice. Most software vendors add AI by calling OpenAI's or Anthropic's APIs directly — meaning customer data is sent to those companies, under a separate set of terms, creating a new vendor relationship their customers never assessed. We intentionally chose not to do this. By running all models through Vertex AI:

• Your data is never sent to Anthropic, OpenAI, or any AI lab. When Aphex uses Claude models, they are hosted and served by Google on Google Cloud infrastructure. Anthropic does not receive, store, or have any access to your prompts or data. We do not use OpenAI at all.

• No new vendor to assess. Aphex already runs on Google Cloud. Using our AI features keeps your data with the same subprocessor, under the same Cloud Data Processing Addendum, that covers the rest of the product. There is no separate AI vendor relationship.

• Your data is never used to train models. Google contractually commits that customer data submitted to Vertex AI is not used to train or improve any models — Google's or its partners'.

One scoped exception: voice transcription uses AssemblyAI (see the provider table below). It receives audio for transcription only — no project data, plans, or records — Aphex has opted out of any training use, and content is deleted within 3 days.

Today, our AI features are implemented within our Diary product. Teams using only our core Planner product will not encounter any AI functionality.

We currently use AI in three main ways within the Diary product:

1. Capturing Site Records Easily

Making it frictionless for site teams to create diary entries through multiple input methods.

Current examples include:

• Voice to Text: Real-time transcription of spoken notes using mobile devices

• Image to Text: Converting handwritten notes from photos into digital text

• Diary Chat: Say or type what happened on site and AI creates and adds the relevant labour, plant, and note cards directly in your site diary

2. Organising and Summarising Site Records

Helping teams compile and structure their daily records efficiently.

Current examples include:

• Diary Summary Generation: Automatically compiling notes, progress updates, and photos into coherent daily summaries

3. Analysing and Finding Information Across Site Records

Enabling teams to extract insights and locate specific information from their project records.

Examples in development:

• Search functionality: Query across multiple diary records to find specific information

• Automated recaps: Scheduled summaries of diary records (e.g., night shift updates)

AI processing is transient: your content is sent to the model, a response is generated, and nothing is retained by the model. Where that processing happens depends on where Google Cloud has deployed the models we use:

Google is expanding regional AI availability continuously, and we track this closely. Our commitment: as Google Cloud deploys AI processing to new regions, we will adopt them — so AI processing progressively aligns with the same regional boundaries as your stored data.

AI is both an opportunity and a risk for construction projects and the clients they serve. That's why we're deliberate not just about how we build AI features, but about how we make them available to customers and users.

Today, our AI features live within Diary — a product built around the unlock AI provides for capturing and making sense of site records. Going forward, we expect AI to play an increasing part in how project orchestration happens. We'll approach that thoughtfully from a user experience perspective, and equally from a governance and risk perspective.

For any change that meaningfully increases the scope of data provided to an AI service, we work through the same questions we'd expect your security team to ask:

• What information needs to be provided to the model to deliver the feature?

• Where is that model hosted and processed?

• Which vendor receives that data, and under what terms?

• What benefit does the user get in return?

Sometimes the answers mean we ship enhancements with AI built in — as we do in Diary today. Sometimes they'll mean we're fundamentally changing the offering — for example, an AI capability directly within Planner — and in those cases we may make it opt-in, so your organisation decides when and whether to adopt it. Either way, this page will always reflect the current state: which features use AI, which providers are involved, and where processing happens.

If your IT or information security team wants to go deeper — architecture, subprocessor terms, or our security documentation — contact us at and we'll walk them through it.