Gartner's AI Trust, Risk and Security Management framework, AI TRiSM, was built on a simple observation: organisations were buying point solutions for AI risk and calling it a strategy. A model monitoring tool here, a red teaming vendor there, a DLP add-on bolted onto the LLM gateway. Each solved a real problem. None of them, alone, gave a security or compliance team an answer to the question that actually matters: is our AI usage, across every model and every team, something we could defend to a regulator, an insurer, or a board.
AI TRiSM organises that answer into four pillars: explainability and model monitoring, ModelOps, AI application security, and privacy. Most vendors in the market today build for one of them and market it as the whole thing. That gap between the framework and what is actually being sold is where we spend most of our time.
The four pillars, and where the market actually is
- Explainability and model monitoring: understanding why a model produced a given output, and tracking its behaviour for drift over time. Well served for traditional ML. Thin for generative and agentic systems, where the "model" making a decision might be a chain of tool calls, not a single inference.
- ModelOps: the operational lifecycle of getting models into production and keeping them there safely, including version control, rollback, and access management. Mature in MLOps tooling. Largely absent for the mixed fleets of frontier, open weight, and fine tuned models that most enterprises now run simultaneously.
- AI application security: securing the applications built on top of models, including prompt injection defence, output validation, and adversarial testing. The fastest growing and most crowded segment, and also the one most vendors treat as the entire framework.
- Privacy: ensuring personal and sensitive data is not exposed to, memorised by, or leaked through a model. Frequently treated as a compliance checkbox rather than a technical control that runs on every single request.
A framework with one pillar built is not a framework
An organisation with strong prompt injection defence and no privacy control at the point of inference has not implemented AI TRiSM. It has implemented AI application security, and it will discover the gap the first time a regulator or an auditor asks about the other three pillars.
Where OBEL™ sits
OBEL™ was not built to be a TRiSM product. It was built to answer a narrower question: how does an organisation route every AI interaction through governance before it reaches a model, regardless of which model, which provider, or which team. That narrower question turns out to map onto all four pillars, because governance that only covers one of them is not governance.
The scrubber runs against every prompt before it leaves your environment. That is the privacy pillar, applied at the point of inference rather than as a policy document. The ARGUS-i classification pipeline and the sovereign block gate cover explainability and monitoring: every interaction is classified, logged, and auditable, and the classification schema does not change based on which model answered the request. Agent authority levels, from read-only through autonomous, and the fallback routing across six or more providers, are ModelOps: the operational controls that keep a mixed model fleet safe and available. And the access control chain, budget enforcement, and audit trail are the application security layer, sitting in front of every request rather than bolted on after an incident.
4
AI TRiSM pillars in Gartner's framework
1
Governance layer most vendors actually ship
100%
OBEL™ interactions scrubbed and classified before model call
Where the industry still has ground to cover
We do not think the framework is fully solved, by us or anyone else. Explainability for agentic workflows, where a task is completed through a chain of tool calls rather than a single model response, is still an open problem. Attributing a bad outcome to the specific decision point that caused it, across a multi step agent run, needs better tooling than the industry has today. We are building toward it with the Intelligence Hub's MITRE ATT&CK style mapping for agent tool calls, but it is early.
The other gap is organisational, not technical. AI TRiSM assumes security, compliance, and AI operations teams are working from the same evidence. In most organisations they are not. The compliance team has a policy document, the security team has a SIEM, and nobody has a single source of truth that both can query. Closing that gap is as much about the audit trail being genuinely shared and genuinely readable by non technical stakeholders as it is about any control being technically sound.
“A framework is not a marketing claim. It is a checklist for what you have not built yet.”
- ninthLABS Ventures
How to check your own position
Ask which of the four pillars your current AI stack actually covers with a technical control, not a policy. If the honest answer is one or two, you have a point solution, not a governance layer, and the gap will surface at the worst possible time: during an incident, an audit, or a procurement review.
References
- [1]Gartner, AI Trust, Risk and Security Management (AI TRiSM)
- [2]NIST AI Risk Management Framework (AI RMF 1.0)
- [3]OWASP Top 10 for LLM Applications
More in Perspective