Posted by 
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 while present that answer so confidently that nobody thinks to check it.
The compliance frameworks arrive at the same three properties from a completely different direction. Nice corroboration but not why I did it.
Observability: see the estate
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 gets the first two properly in place. Tracing is the one that has to wait, mostly because off-the-shelf software will not hand a request identifier to the next system in the chain. What you can do in the meantime is make sure the pieces are ready for it: a single clock across every device, records that arrive with a reliable source, and one place they all land. Correlation now, tracing when there is something worth tracing.
Which brings the real work of this phase back to coverage. And coverage means everything, not most things.
Monitoring 80 percent of an estate does not get you 80 percent of the benefit. The 20 percent you cannot see is where the quiet problem will be, because it is the only place a problem can stay quiet. Laptops count too, not just servers, which is how endpoint detection ended up in this phase instead of in some separate security project six months down the track.
Then when it comes to continuity. A machine that reported yesterday and said nothing today is telling you something, but only if there is something listening for the silence. Observability is not a dashboard you check. It is something noticing that a machine has stopped talking, and telling you.
Accountability: review before too late.
Why it is important, because you cannot hold a model accountable.
When a feature goes live, someone need to put their name on it. Usually it is an organisational question, not a technical one: it is not about whether this thing can run or not, but who is accountable when it gets something wrong. That question gets harder as the system makes more decisions on its own. The usual practice is let somebody review and confirm before AI make a crucial decision. That changes how the alerting gets built and that is why we involve rules.
Everything in this phase fires from a rule. A rule will not report a disk failure that did not happen, and it will not quietly stop reporting because something upstream failed to load. When an auditor asks what happened last Tuesday or the reviewer need to confirm, the system can walk them through it line by line. Accountability is not a document saying who is responsible. It is being able to point at whatever made the call and explain why.
Authenticity: trust the record
Logs are not just operational noise. They are what you fall back on when something has gone wrong and somebody wants to know what happened. It should be the part of the source of truth.
To uphold the authenticity, two things have to be held. the first is the record has not been altered since it was written. It really came from the machine it says it came from. The second is the timestamps, because an event with no reliable timestamps cannot be lined up against others. This is the fragile one. Just image what would happen if the clocks drift half a minute across three sites, you will find incident timeline becomes a matter of opinion.
Back to the architect, what actually got built
As you can see from above, we can try to understand the design of purpose in three perspectives.
Observability
First of all, the two systems, deterministic monitoring and log & telemetry hub, kept apart on purpose.
MON01 (deterministic monitoring) does metrics and threshold alerts, such as disk over a line, service stopped, device not answering. This is the thing that wakes someone up, and the technology should be deliberately dull but reliable.
LOG01 (log & telemetry hub) collects logs and telemetry, such as syslog from the network gears, event data from the Windows servers, flow data from the core switches. It sits in its own network segment (vlan 40), which comes back later.
EDR agents go onto every workstation and server. Before this, the only inspection in these systems was on inbound mail at the edge.
To go upstair of new phase, the criterion is a number rather than a vibe: 95 percent of managed devices reporting continuously, false report under 10 percent. A monitoring system that cries wolf usually gets ignored, but an ignored monitoring system is worse than none, because now everyone believes someone is watching. We just need to set the threshold alerts properly.
One thing that is easy to miss. MON01 is a virtual machine sitting on the same host as most of what it watches. Lose the host machine means you lose the services and the thing that would have told you about the accident. The fix costs nothing. MON01 sends a heartbeat out to something external, and if the heartbeat stops, that something raises the alarm. Whatever checks that the monitoring is alive has to live when the monitoring does not. Further, we could build some redundancy here in a future upgrade by adding an extra host.
Accountability
When thresholds fire, a human can decide whether it matters. An on-call roster with a written escalation path says who that human is, and who they call if it turns out to be bigger than they thought. That is the whole system involving management. Every alert ends up with somebody’s name against it.
It looks like going backwards. But I think it is the opposite. At some point somebody is going to ask whether a piece of automation is good enough to trust, and answering that needs a baseline. For instance, how many alerts go off in a normal week, how many turn out to be nothing, and how long it actually takes someone to work that out. If nobody counts while people are still doing the work by hand, you have nothing to measure against later. And “it seems to be helping” is not an answer anyone will put their name to. Not to mention that people are willing be accountable for their own reviews of AI “decisions” go live.
The exit criteria are numbers for the same reason. Without a number, there is always a reason to wait one more month.
Authenticity
In cyber security perspective, telemetry should gets pushed, not pulled. Every server sends its own data in, making the record traceable to a source. The alternative is a collector that reaches out and pulls, and to do that it has to hold credentials that work on every machine in the estate, which turns your log server into the most valuable box on the network. Takes it and you have a key to everything it watches. Push it the other way and the collector holds nothing at all, and a compromised host cannot use it as a path to anywhere else.
Also, logs should land in immutable storage, kept twelve months. Immutable because clearing the logs is usually the first thing an intruder does. Twelve months because intrusions usually get found long after they start. If the retention is shorter than that gap, the evidence of how they got in expired before anyone went inspecting.
Everything syncs to one clock. This is the the least interesting item in the phase but it decides whether the rest of it is usable.
One more thing worth mentioning is the network segment should gets separated here on day one. For now the only thing in it is LOG01. Drawing the boundary early costs almost nothing. On the contrary, moving a system into one later means changing every firewall rule, every config file and every script that already points at its old address.
Everything above is infrastructure a 200-person company ought to have anyway.
Disk fills up and somebody knows. A service dies and an alert fires. Something bad happens and there are logs to look at that the attacker could not delete. None of that is an AI requirement. It is the baseline, and most mid-sized estates are at about two thirds of it.
So Phase Zero is not a bet. Cancel the whole AI idea the day it finishes and the three months still paid for themselves. All the AI ambition changed was the order of the work, and the fact that somebody insisted on exit criteria you could actually measure.
Do this part first. Let the AI be the reason you finally got around to it.
Part 3 is about what happens when a model does turn up, and about one decision that goes against everything Part 1 argued for. There is a single server in this build that was deliberately left on bare metal.
Part 3: The One Box We Left Alone