Part 1 (Why Virtualisation Comes First) explained why virtualisation matters: it makes change easier to reverse. That is essential when testing an AI-driven network product. You change one variable, observe the result, and roll it back if the outcome is not what you expected.

The logical network diagram below shows the back-office environment split across three Hyper-V hosts, one for each security zone: Internal, AI and DMZ. In Part 1, I moved quickly past an important part of this architecture. This article comes back to it.


Before AI touches anything, Phase Zero must establish three conditions: you can see the IT infrastructure environment, someone is accountable for what happens, and you can trust the records the infrastructure produces. I group these conditions under three headings: observability, accountability and authenticity (OAA). None of them is specific to AI deployment. They are standard concerns for a compliance auditor, yet many organisations have implemented them only partially. They also form the foundation on which the AI system will operate. Get them wrong, and the audit and the AI project can fail for the same underlying reason.

That is a central argument: AI will not fix poor data quality but it will expose bad data. It reaches the wrong answer faster but present that ansower so confidently that nobody consider to check it. But at phase zero, we should consider the compliance. We can first check the frameworks related to those conditions (OAA) from different angles. That is useful checklist, although compliance itself was not the reason I designed the phase this way.

Observability: See the Environment

The industry usually breaks observability into three pillars. Dynatrace describes them as metrics, the numbers that track health over time such as CPU and memory; logs, the text records of specific events and errors as they occur; and traces, the maps that follow a single request as it moves between services.

Phase Zero puts metrics and logs properly in place. Full tracing has to wait because most off-the-shelf applications do not pass a request identifier from one system to the next. In the meantime, the environment can still be prepared for it: synchronise every device to the same clock, identify the source of every record reliably, and send all records to one central location. Also, correlate events and add end-to-end tracing when the applications can support it.

That brings us to the real work of this phase: complete coverage, not partial coverage.

Monitoring 80% of an IT environment does not deliver 80% of the benefit. Problems can remain hidden in the 20% you cannot see, precisely because nothing there is reporting them. Laptops count as well as servers. That is why endpoint detection belongs in this phase, rather than in a separate security project six months later.

Silence is also a signal. A machine that reported yesterday but says nothing today may be telling you that something is wrong, but only if another system is watching for that silence we can have a little bit of relief. Observability is not simply a dashboard that someone remembers to check. It is the ability to notice the status of machine and alert the right person if necessary.

Accountability: Keep a Human in the Decision Chain

Accountability matters because responsibility cannot end with the model. A person or an organisation must own the decision and its consequences.

When a feature goes live, someone needs to put their name on it. This is usually an organisational question rather than a technical one. The issue is not only whether the feature can run, but who is accountable when it gets something wrong. That question becomes harder as the system makes more decisions on its own. For high-impact decisions, a human should review and confirm the recommendation before action is taken. Phase Zero therefore needs clear review points, rule-based alerts and an escalation path to a named owner.

Every alert in this phase is generated by an explicit rule. Rules can still be poorly designed, but they are visible, testable and repeatable. If an auditor asks what happened last Tuesday, or a reviewer needs to verify a decision, the system can show which condition fired, what evidence was available and who responded. Accountability is more than a document naming the responsible person. It also requires a record of how a decision was reached.

Authenticity: Trust the Record

Logs are not just operational noise. When something goes wrong and people need to reconstruct what happened, logs become evidence. They are not the whole source of truth, but they must be a reliable part of it.

A trustworthy record needs three properties. Its source must be verifiable, its contents must not have been altered after collection, and its timestamp must be reliable. Time is often the fragile part. If clocks across three sites drift by even half a minute, reconstructing an incident timeline can become a matter of opinion rather than evidence.

From Principles to Architecture: What Phase Zero Actually Built

The diagram above shows how those three principles shaped the architecture. Here is what the design provides for observability, accountability and authenticity.

Observability

The design deliberately separates deterministic monitoring from the log and telemetry hub. They serve different purposes and should not fail together.

MON01 provides deterministic monitoring through metrics and threshold-based alerts: such as disk usage above a limit, a stopped service, or a device that no longer responds. This is the system that wakes someone up. Its technology should be deliberately dull, predictable and reliable.

LOG01 is the log & telemetry hub that collects logs and telemetry: such as syslog from network devices, Windows event data from servers, and flow data from the core switches. It sits in its own network segment, VLAN 40, for isolation and future expansion.

EDR agents are installed on every workstation and server. Previously, the environment inspected only inbound email at the network edge. EDR extends visibility to activity on the endpoints themselves.

Progress to the next phase is based on three measurable exit criteria for this project: at least 95% of managed devices reporting continuously; an alert false-positive rate below 10%; and one completed forensic search drill in which the team reconstructs a simulated incident from the central logs. The first two criteria measure coverage and signal quality. The drill proves that the records are not only being collected, but can also be found, correlated and used when something goes wrong.

One failure mode is easy to miss: MON01 is a virtual machine on the same host as many of the services it monitors. If that host fails, you lose both the services and the system that should report the failure. The immediate fix costs almost nothing. MON01 sends a heartbeat to an external service, which raises an alert if the heartbeat stops. The system that checks whether monitoring is alive must survive when the monitoring system does not. A later upgrade could add stronger redundancy across hosts.

Accountability

When a threshold is crossed, a human decides whether it matters. An on-call roster identifies that person, while a written escalation path says whom they should contact if the issue is larger than expected. This is where technical monitoring becomes operational accountability: every alert has an owner, a response and a recorded outcome.

Keeping humans in the loop may look like a step backwards, but it creates the baseline needed for responsible automation. Before deciding whether automation is trustworthy, you need to know what normal operations look like: how many alerts occur in a typical week, how many are false positives, and how long people take to assess them.

If you do not measure the work while humans still perform it, there will be nothing to compare the automated system against later. “It seems to be helping” is not evidence that anyone should sign off on. Before an AI-assisted decision goes live, a named person must be willing to take responsibility for reviewing it.

The exit criteria are numerical for the same reason. Without a measurable threshold, there is always an argument for waiting one more month, or for moving ahead before the system is ready.

Authenticity

From a cybersecurity perspective, telemetry should be pushed to the collector rather than pulled from each source. Each server sends its own data, making every record traceable to its origin. A pull-based collector needs credentials that work across the environment, which can turn the log server into one of the most valuable targets on the network. Compromise it, and an attacker may gain access to every system it monitors. A push-based design removes the need for those broad collection credentials and reduces the collector’s value as a path into other systems.

Logs are written to immutable storage and retained for twelve months. Immutability matters because an attacker may try to delete or alter evidence. The retention period matters because an investigation often begins long after the initial compromise. If the logs expire before the investigation starts, the evidence needed to reconstruct the incident may already be gone. Twelve months is the retention target chosen for this environment but other organisations should set the period according to their legal, operational and risk requirements.

Every system synchronises to the same clock. It is the least exciting item in the phase, but it determines whether all the other records can be correlated and used.her the rest of it is usable.

One more thing worth mentioning: the dedicated network segment should also be created on day one, even though LOG01 is initially the only system in it. Drawing the boundary early costs very little. Moving the system later would mean changing every firewall rule, configuration file and script that points to its old address.


Everything described above is infrastructure that an organisation of around 200 people should have anyway.

A disk fills up, and someone knows. A service stops, and an alert fires. Something goes wrong, and investigators have logs that the attacker could not erase. None of this is an AI requirement. It is a basic operational baseline. In my experience, many mid-sized IT environments have only part of it in place.

Phase Zero is therefore not a bet on AI. Even if the AI initiative stopped after Phase Zero, the work completed during those three months would still deliver value. The AI ambition changed only the order of the work. It also forced us to define exit criteria that could be measured.

Do this work first. Let the AI project be the reason you finally get around to it.

Part 3 looks at what changes when an AI model finally enters the architecture. It also examines one decision that appears to contradict everything I argued in Part 1: one server in this build was deliberately left on bare metal.

References

  1. Australian Signals Directorate. Guidelines for System Monitoring, Information Security Manual. Cyber.gov.au.
    https://www.cyber.gov.au/resources-business-and-government/essential-cybersecurity/ism/cybersecurity-guidelines/guidelines-system-monitoring
  2. Australian Signals Directorate et al. (2024). Best Practices for Event Logging and Threat Detection. Cyber.gov.au.
    https://www.cyber.gov.au/business-government/detecting-responding-to-threats/event-logging/best-practices-for-event-logging-and-threat-detection
  3. Microsoft. Setting up a Source Initiated Subscription. Microsoft Learn.
    https://learn.microsoft.com/en-us/windows/win32/wec/setting-up-a-source-initiated-subscription
  4. Microsoft. Windows Event Collector. Microsoft Learn.
    https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector
  5. Dynatrace. How to Get the Answers You Deserve Using the Three Pillars of Observability. Dynatrace Blog.
    https://www.dynatrace.com/news/blog/how-to-get-the-answers-you-deserve-using-the-three-pillars-of-observability/
  6. Australian Signals Directorate. Essential Eight Maturity Model. Cyber.gov.au.
    https://www.cyber.gov.au/resources-business-and-government/essential-cybersecurity/essential-eight/essential-eight-maturity-model
  7. Mandiant. M-Trends: Special Report. Mandiant / Google Cloud.
    https://www.mandiant.com/m-trends

Leave a Reply

Your email address will not be published. Required fields are marked *