AI security discussions still spend too much time focused on the model itself. Is the model safe? Can it be jailbroken? Can it hallucinate? Can the prompt be manipulated?
Those are valid questions, but enterprise AI risk is much broader than the model.
That is why the approach in AI Security Architecture: A Practical Enterprise Framework – Part 2 makes sense. AI security has to be designed across the environment that surrounds the model: identity, access, data, applications, APIs, agents, infrastructure, monitoring and governance.
An AI system can be perfectly well behaved and still create serious risk if it is connected to the wrong data, given excessive permissions or allowed to call powerful tools without meaningful controls.
This is where architecture becomes important.
The first part of the framework establishes the broader enterprise foundation in AI Security Architecture: A Practical Enterprise Framework – Part 1. Part 2 takes that thinking further by focusing on how controls should be applied around AI capabilities rather than treating AI as an isolated technology.
That distinction matters because modern AI is increasingly connected.
An AI assistant may access documents. A coding agent may interact with repositories and terminals. An enterprise agent may call APIs, invoke workflows, retrieve information from multiple systems and perform actions on behalf of users.
At that point, the security question is no longer simply whether the model produces a safe answer.
It becomes:
What identity is the AI using?
What is it allowed to access?
Which data can it retrieve?
Which actions can it perform?
What happens when one control fails?
Can the organisation see what it did afterwards?
This is much closer to traditional security architecture than many AI discussions suggest.
The model is only one component.
The real security boundary is the combination of identity, permission, data access, tool access, network reachability and monitoring surrounding it.
That is why enterprise AI security should be designed as an architecture problem from the beginning, not added later as another layer of prompt filtering.
The safest AI is not necessarily the model with the most restrictions.
It is the AI operating inside an environment where trust is deliberate, permissions are constrained, actions are observable and failure can be contained.