Services

Architecture should follow consequence.

Design is where most of the risk in an AI project is either removed or locked in. We decide what runs where, what a person must approve, and what gets written down, before anything is built.

Book a conversation (opens in a new tab)

Where it runs

Three places a system can live.

There is no best answer, only the right one for the information involved. Many businesses end up using two of the three.

OptionSuitsWhere the data goesWhat to watch
Commercial cloud servicePublic or low sensitivity information, and getting started quickly.To the provider, under the terms of your contract. Those terms decide whether it is kept.Read the retention and training terms. The default settings are often not the ones you want.
Private cloud in AustraliaCustomer, staff and commercial information you would not want overseas.To servers in Australia that you or your partner control.Costs more to set up. Needs someone to look after it.
On your premisesInformation covered by contract, regulation or security requirements.Nowhere. It stays inside your building.You own the hardware and its upkeep. Models may be smaller than the largest cloud ones.
A plain comparison of where an AI system can run. Your own contracts and obligations decide the detail.

Who checks what

Review levels are designed in, not added later.

Each kind of output is given a review level when the system is designed. The level is set by the cost of being wrong, and it is recorded so anyone can see why.

  1. Automatic

    Being wrong costs nothing and is easily undone.

    For example

    Filing a document in the right folder.

  2. Spot check

    Being wrong is a nuisance. A person samples the work.

    For example

    Matching invoices to purchase orders.

  3. Full review

    Being wrong reaches a customer. A person reads every one.

    For example

    A reply to a complaint.

  4. Director sign off

    Being wrong is costly or unsafe. A senior person approves.

    For example

    A change to a safety procedure.

The four review levels. Examples are illustrative.

What a design contains

The document your builder, your board and your insurer can all read.

  1. What is code and what is a model

    Sums, scores and rules are written as code, where they are exact. Reading, drafting and sorting go to a model, with a review.

  2. What the system may touch

    A list of the information it can read and the actions it can take. Anything not on the list is refused.

  3. An audit trail

    Every step is recorded so a decision can be replayed later. That is more than most human processes can offer.

  4. What happens when it fails

    How you will notice, who is told, and how the work carries on without it.

We don't let a pressure vessel operate without inspection. We shouldn't let an AI model operate without verification.

Shane Scriven, Managing Director

Questions we are asked

Before you commit to a design.

Can we design now and build with someone else?

Yes. The design is written so any competent builder can work from it, including your own staff or your current IT provider.

Do we have to choose one place for everything?

No. It is common to run routine work on a commercial cloud service and sensitive work privately. The design says which is which, and why.

What about systems we already have?

We design around them. A tool that needs you to replace your accounting or job system first is rarely the right first project.

Next

Talk through what you are planning.

Thirty minutes is usually enough to tell whether your idea needs a design, a smaller first step, or nothing at all.