Where does your data actually go when you use AI?

01 / STORAGE

Where is our information stored?

Start with the simplest question.

When your team uploads a drawing, contract or report to an AI system, where does that information live?

It could be stored:

• by the AI technology provider;
• within Microsoft Azure, AWS or another cloud environment;
• within your organisation's own cloud environment; or
• on infrastructure controlled directly by your organisation.

This is what people are usually talking about when they refer to hosting.

For some organisations, where information is hosted will be an important requirement. Your IT team or clients may already have rules governing where particular types of information can be stored.

But there is an important catch.

Knowing where the application is hosted doesn't necessarily tell you where your information goes when the AI actually processes it.

That's the next question.

02 / PROCESSING

Does our information leave our environment when AI processes it?

Imagine your commercial team wants an AI system to review a tender return.

The document might be stored safely within an approved environment.

But for AI to analyse it, relevant information may need to be sent to an AI model.

This processing is sometimes called inference.

You don't really need to remember the term.

What matters is understanding that where your AI system is hosted and where the AI model processes your information aren't necessarily the same place.

For example, a system might be hosted within your organisation's cloud environment while using an external AI model to perform a particular task.

A good provider should be able to answer that clearly.

03 / TRAINING

Is our information used to train the AI?

This is probably the question most businesses already know to ask.

There's an understandable concern that giving information to an AI system means that information will somehow become part of the model and potentially influence what it tells other people.

But using an AI model and training an AI model are different things.

Many business and API-based AI services provide controls or contractual commitments around whether customer data is used for model training.

So you should absolutely ask:

“Will any of our information be used to train or improve an AI model?”

But don't stop there.

“We don't train on your data” doesn't necessarily mean “we don't retain your data.”

Those are different questions.

04 / RETENTION

Is anything kept after the AI has processed it?

Suppose an AI model receives part of a specification, processes it and returns an answer.

What happens next?

This is known as data retention.

The appropriate answer may differ depending on the technology being used and the purpose of the system.

The important thing is that there is an answer.

This distinction is worth remembering:

Not used for training doesn't necessarily mean not retained.

For a business handling commercially sensitive project information, both questions matter.

05 / ACCESS

Who could actually see our information?

AI security discussions can quickly become focused on servers, models and cloud infrastructure.

Sometimes a much simpler question is just as important:

Who can access the information?

Think about a few examples.

These aren't particularly exotic AI risks.

They're familiar information-security questions being applied to a new technology.

If you're going to give a system access to contracts, employee information, tender returns or client documents, you should understand who else could potentially access them.

06 / MINIMISATION

What about sensitive information?

There is another useful principle here:

An AI model shouldn't receive information it doesn't need.

Suppose an AI system is reviewing a document for a particular purpose.

It may not need every piece of information contained within that document.

Depending on the process, sensitive information can sometimes be removed or redacted before anything is sent to an AI model.

That might include personal information such as names, email addresses or telephone numbers.

But redaction isn't a magic solution.

A cost plan with every person's name removed is still a commercially sensitive cost plan.

A tender return can contain confidential information without containing any personal information at all.

So the better question is:

“What information does the AI actually need to perform this task?”

The less unnecessary information you expose, the less there is to protect.

07 / DATA JOURNEY

What might the journey actually look like?

Take a construction business using AI to review project documentation.

The journey might look something like this:

The exact journey will differ between systems.

That's precisely why it's worth asking.

“Uses AI” tells you almost nothing about what happens to your data.

08 / PROVIDER CHECKLIST

Five questions to take to your AI provider

You don't need to walk into a meeting asking about model architecture or cloud infrastructure.

Start with these:

The answers don't necessarily need to be the most restrictive possible.

Different processes carry different levels of risk.

An internal system helping organise relatively low-risk information may justify a different approach from one reviewing confidential contracts or processing employee information.

What matters is that somebody has understood the risk and made a deliberate decision about the controls required.

09 / ASSURANCE

“We're secure” isn't enough

Most technology providers will tell you that they take security seriously.

That's reassuring, but it isn't particularly informative.

The more useful conversation is specific:

Those questions allow you to understand the actual journey your information takes rather than relying on a broad security assurance.

And if your provider can't explain that journey clearly, you probably don't yet have enough information to make an informed decision.

10 / LEADERSHIP

You don't need to become an AI infrastructure expert

For most property and construction leaders, that's not your job.

You shouldn't need to understand every component sitting behind an AI system.

You don't need to become an AI infrastructure expert. But your provider should.

And they should be able to explain it to you in plain English.

As AI becomes involved in more of the information your organisation handles, understanding where that information goes needs to become a normal part of evaluating a solution.

Not because every AI system is inherently dangerous.

But because good AI adoption means understanding the process, understanding the information involved and putting controls around it that are proportionate to the risk.

The same principle applies when deciding where your organisation should start with AI: begin with the business need, then understand the process and risk before choosing the technology.

Start with the business.
Understand the risk.
Then design the technology around it.

The BUILD™ framework sets out how we take an opportunity through assessment, implementation, review and responsible development.