Why auditability is becoming the new standard of trust for AI systems.
The security review starts in a familiar way. The diagram is on the screen. Boxes and lines are neatly aligned. Someone points at the controls and says they are in place.
Heads nod around the table.
Then the question shifts:
- Who accessed this model last week?
- Which data was used during inference?
- Where was this policy enforced across cloud, network, and application?
No one says anything for a moment. Not because the answers are unknown, but because they live in different tools, owned by different teams, logged in different formats.
That pause is usually the first signal. Security is no longer assessed by what is installed or configured. It is assessed by what can be shown, step by step, when someone asks.
For AI, that difference matters. Regulations like the AI Act and NIS2 do not introduce unfamiliar ideas. They change what is expected in practice. Trust is no longer assumed based on design. It has to be demonstrated through evidence that exists while the system is running.
Auditability is now what determines whether security holds up under scrutiny.
When security was still based on trust
For a long time, security was checked by presence. A firewall at the edge. Access rules on paper. A checklist confirming that the right components were installed.
If the architecture looked sensible and the vendors were known, that was often enough. Audits focused on setup. Review meetings stayed close to diagrams and policies.
That way of working fit a slower environment. Workloads changed infrequently. Data stayed in fixed locations. Most actions were triggered by people, not by systems acting on their own.
AI breaks that pattern.
Models are updated. Data moves between services. Decisions happen automatically, often without anyone watching in real time. In that setting, confidence based on design alone starts to slip, not because teams are careless, but because the system keeps changing.
What used to feel reassuring now raises a different question. Not what is in place, but what actually happened.
Why audits changed the conversation
The change did not begin with a new tool or a new threat. It began with a question asked across a table.
Not whether controls exist, but whether they can be followed. Not whether access is restricted, but who actually accessed what, on which day, and under which rule.
In an audit today, a diagram is not enough. An auditor points at a log entry and asks how it connects to a model run, a data source, or a policy decision. The expectation is no longer a snapshot. It is a trace.
A trace means being able to follow one action from start to finish, without gaps.
The AI Act and NIS2 did not introduce new ideas. Most teams already recognise the principles. What changed is that those principles must now be shown, clearly and consistently, at the moment the question is asked.
That is where the tension appears. Logs sit in different systems. Policies are enforced in different layers. Timelines do not line up. Answering a simple question means opening several tools and stitching the story together by hand.
Once that expectation is set, it does not stay inside the audit room. It influences how security is built and reviewed every day.
Where organisations get stuck
The problem rarely looks like a failure of security. It looks like hesitation.
A team is asked how a specific AI output was produced. Someone pulls up the model version. Someone else searches for the data source. A third person checks access rights. The answers exist, but they do not meet in one place.
This often becomes visible during a DPIA. Most fields are filled in. One question remains open. Someone says they will follow up. The form stays unfinished for weeks.
Security information is spread across cloud platforms, on-premise systems, and specialised tools. Each part does its job. Together, they do not tell a single, continuous story.
That is the moment auditability stops being theoretical and starts slowing real work.
Auditability is not documentation
When the word auditability comes up, many teams think of documents. Reports. Diagrams. Explanations of how controls are meant to work.
That is not what is being asked for.
Auditability means being able to show what happened while the system was running. Where an action took place. Which rule allowed it. And when that decision was recorded.
A document can explain intent. It cannot show behavior. Behavior is captured by what the environment records as events unfold.
For AI systems, this matters immediately. Decisions are made continuously, often without a person watching. Evidence has to exist at the moment those decisions are made, not assembled later under pressure.
When auditability is treated as paperwork, teams fall behind. When it is built into daily operation, answers are already there when the question comes.
What breaks when security is fragmented
Security usually does not fail in one clear moment. It slips when no one can see how actions connect.
In many organisations, one screen shows cloud logs, another shows network alerts, and a third lists access rights. Each screen looks fine on its own. None of them explains what happened end to end.
An alert pops up in one tool. Someone checks another system to see what followed. The trail breaks in between. A rule applied at the network layer has no clear link to what ran inside a container or which model answered a request.
For AI workloads, this lack of connection becomes visible fast. A model runs in a container. Data flows in from another service. Inference requests arrive at different moments. Without a single view, teams are left guessing whether what they see is expected or simply unclear.
This is also where shadow AI appears. A team spins up a model outside the usual path to avoid waiting. Not to bypass security, but to get work done while approvals and visibility lag behind.
Fragmentation does not just weaken protection. It slows audits, stretches incident reviews, and makes daily work less predictable.
End-to-end security starts with visibility
Auditability does not begin with another control. It begins with being able to see.
End-to-end security means having a clear view of what happens across the AI stack as it runs. Not only at the edge, but inside workloads, between services, and at the moment decisions are made.
That view is built by placing signals side by side. A network connection. A workload starting. An identity making a request. An inference being logged.
Each signal is something the system already records while it runs. When those signals line up, behavior becomes traceable instead of assumed.
In an AI environment, this makes a practical difference. A request can be followed from the moment it hits a model, through the data it touched, to the rule that allowed it, and back to the identity that triggered it.
When that path is visible, audit questions stop turning into investigations. They become checks that can be answered on the spot.
From firewall to firewalling
Traditional security relied on a single checkpoint. Traffic passed through a firewall, rules were applied there, and everything behind it was treated as trusted.
That setup does not fit how AI systems run today.
AI workloads are spread out. Models run in containers. Data moves between services. Decisions trigger actions across several layers. Enforcing rules in one place leaves too much unseen.
Firewalling takes a different approach. The same intent is enforced in several places, close to where activity happens.
At the network layer. At the workload itself. Inside the application that makes the decision.
Rules move with the workload. Each enforcement point shows not only that a rule exists, but where it was applied and when. That makes behavior visible instead of implied.
By closing the distance between policy and action, firewalling removes the gaps audits tend to uncover.
Why AI needs a different security lens
AI brings situations that older systems never had to handle.
A model sits in a container. It is trained on one dataset, updated a month later, and reused in a different setting. Each version leaves a trace that has to be followed, not assumed.
Some issues start before anything runs. A dependency is pulled from a registry. A model image is updated. A weakness is introduced long before the first request reaches production.
Other issues appear while the system is live. A prompt nudges a model in an unexpected direction. Inputs change step by step. The output looks valid, yet no one can point to the moment intent shifted.
These moments rarely trigger alarms. Nothing is blocked. Nothing fails outright. Without a clear record of what happened, they pass unnoticed.
Why security-by-design makes audits boring
When security is added afterwards, audits turn into cleanup work.
Logs are pulled from different systems. Timelines are rebuilt. People search for decisions that were made weeks earlier. Meetings fill the gaps that systems did not record.
Security-by-design changes that pattern.
When logging, access checks, and enforcement are part of the setup, evidence appears as the system runs. A model version is noted when it goes live. An inference is recorded when it happens. An access decision leaves a timestamped trail.
Audits still take place. They follow a predictable path, without surprises. For most teams, that kind of audit is the easiest one to handle.
One check every CIO and CISO can do tomorrow
Ask one simple question.
If a request arrives tomorrow morning, can you point to who accessed the model, which data it touched, which rule allowed it, and where that decision was written down.
If all of that sits in one place, the system is already auditable.
If it takes emails, log exports, and time alignment to answer, the gap is still there.
Security today is defined by what you can show.
Want to learn more about how end-to-end security and auditability work in practice for AI environments? Get in touch with experts Michel or Jan and contact us.
