AI TRiSM compliance under the EU AI Act and US AI order

At a glance

What this is: This analysis explains how the EU AI Act and the US Executive Order on AI turn AI TRiSM into a governance requirement for GenAI and LLM use.

Why it matters: It matters because IAM, privacy, legal, and security teams now need shared controls for AI systems that create disclosure, documentation, and accountability obligations across human, NHI, and emerging agentic workflows.

👉 Read Lasso Security's analysis of AI TRiSM compliance under the EU AI Act and US AI order

Context

AI TRiSM is the governance layer that helps organisations assess, document, and control the risks created by generative AI and LLM deployments. The article argues that regulation is now catching up with the operational problems security teams already see in AI use, especially around transparency, privacy, and responsibility.

For IAM and security leaders, the important question is no longer whether AI touches identity governance, but how quickly current review, inventory, and approval processes can absorb AI systems as governed assets. That is where policy, procurement, and security controls start to overlap, and where existing models often break down.

Key questions

Q: How should organisations govern AI systems under new regulation?

A: Treat AI governance as a cross-functional control process, not a model-only review. Build an inventory, assign ownership, document permitted use, and connect legal, privacy, procurement, and security approvals to the same intake workflow. Compliance becomes credible only when policy is linked to evidence, logging, and reviewable accountability.

Q: Why do AI regulations create identity governance work?

A: Because AI services are now governed assets that can touch data, users, and downstream systems. Identity teams must know what the AI is allowed to access, who approved that access, and how the access is reviewed over time. Without that, disclosure and documentation obligations cannot be reliably enforced.

Q: What do organisations get wrong about AI compliance programmes?

A: They often stop at policy statements, committee formation, or vendor questionnaires. Those are necessary, but they do not prove that the AI system is inventoried, logged, bounded, and accountable. The real failure is treating compliance as documentation work instead of operational control.

Q: Who is accountable when an AI system violates policy or privacy rules?

A: Accountability should sit with the business owner, the security approver, and the vendor relationship owner, not with a generic AI task force alone. If a system is deployed without a clear owner and review path, the organisation has created an accountability gap that regulatory scrutiny will expose.

Technical breakdown

What AI TRiSM changes in regulated AI governance

AI TRiSM, short for AI trust, risk and security management, is the control layer that sits between model deployment and organisational approval. In practice, it combines inventory, risk assessment, disclosure, testing, and policy enforcement so that AI systems are governed like other enterprise assets. Under the EU AI Act and the US Executive Order on AI, that means AI is no longer just a technical deployment choice. It becomes a managed compliance surface with obligations attached to use, not just build.

Practical implication: treat AI TRiSM as part of governance design, not as a separate security project.

How transparency and documentation requirements affect AI systems

The article highlights two recurring regulatory demands: users must know when they are interacting with AI, and providers must document the system and its training data. That combination matters because transparency is not just a disclosure banner, it is an accountability trail. High-risk systems also bring stronger logging, documentation, and data quality expectations, which means teams need evidence that can survive audit, legal review, and internal challenge.

Practical implication: build evidence collection into AI onboarding, not after deployment.

Why AI inventory and vendor review become identity problems

Once AI systems are treated as governed services, the operating question becomes who approved them, who maintains them, and which data and identities they can touch. That makes AI inventory a governance control, not a spreadsheet exercise. It also pulls procurement and legal into the same decision path as security, because an unmanaged AI vendor can create policy, privacy, and access gaps even if the model itself is technically sound.

Practical implication: require a complete AI service inventory with ownership, access scope, and review cadence.

NHI Mgmt Group analysis

AI regulation is turning model governance into identity governance. The article shows that compliance is no longer limited to model safety statements or policy language. Once disclosure, documentation, and accountability are required, the organisation must know which AI services exist, who approves them, and what they can access. That makes AI TRiSM a governance discipline shared by legal, security, procurement, and IAM teams, not a standalone AI programme.

The AI risk register is now a control register. The article's emphasis on risk assessment, vendor evaluation, and prohibited uses means organisations cannot separate AI approval from operational control design. The practical result is that every deployed AI service needs an owner, a documented purpose, and a reviewable boundary for data and access. Practitioners should treat AI onboarding as a governed entitlement process, not an innovation exception.

Disclosure obligations expose where current governance is too shallow. Requirements to inform users that they are interacting with AI and to publish documentation force organisations to prove control, not just claim it. That creates pressure on inventory quality, logging, and lifecycle oversight. Teams that cannot answer what AI is in use, where it sits, and who is accountable will struggle to demonstrate compliance.

Regulated AI will reward organisations that can connect policy to enforcement. The article is clear that compliance is not achieved by committees alone. The gap is between stated policy and operational proof. Organisations that can map legal requirements to technical controls, review cadence, and access governance will have a much lower exposure than teams relying on informal oversight.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Another finding from our research: Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to the same report.
• For a forward view, see also: OWASP Agentic AI Top 10 for the control patterns that matter as AI systems become more autonomous.

What this signals

The immediate signal for practitioners is that AI governance is moving from policy drafting to control evidence. If your programme cannot show ownership, access boundaries, and review trails for AI services, it will struggle to support both regulatory scrutiny and internal assurance.

AI control debt: the gap between what the organisation says about AI and what it can prove in logs, inventory, and approval records will become the defining governance weakness. Teams should use AI onboarding to force clarity on data access, accountable owners, and lifecycle review.

The broader trend is that AI regulation is pushing identity teams to absorb new classes of non-human access into the same operating discipline used for workloads and service accounts. That makes lifecycle governance and entitlement visibility core capabilities, not optional maturity extras.

For practitioners

• Create a governed AI inventory Record every AI service, model, and vendor relationship with an owner, business purpose, data scope, and review date. Tie the inventory to procurement and security approval so shadow AI cannot bypass policy review.
• Align legal, procurement, and security approval paths Use one intake process for new AI use cases so risk, privacy, and access questions are assessed together. A single decision record should capture permitted use, prohibited use, and escalation ownership.
• Require evidence for transparency and logging controls Document how users are informed they are interacting with AI, how model outputs are traced, and what logs are retained for review. Make audit evidence part of deployment readiness rather than a post-incident exercise.
• Map AI systems to access and data boundaries Define which identities, datasets, and downstream services each AI system can reach. Review those boundaries on a fixed cadence so approved use does not drift into unapproved access patterns.

Key takeaways

• The article shows that AI regulation is no longer a policy discussion only. It is an operational governance problem that touches identity, access, privacy, and accountability.
• Disclosure, documentation, and logging requirements make AI inventory and ownership mandatory controls, not administrative nice-to-haves.
• Practitioners should connect AI approval, access boundaries, and review cadence into one controlled workflow before deployment grows faster than governance.

Key terms

• AI TRiSM: AI trust, risk and security management is the control layer used to govern AI systems across policy, risk, and security. In practice, it combines inventory, testing, documentation, monitoring, and accountability so AI can be approved and operated under defined guardrails.
• General Purpose AI System: A general purpose AI system is a model or service that can be used across multiple tasks rather than for one narrow function. Under regulation, that broad usability increases governance pressure because the same system can be repurposed into different business, privacy, and security contexts.
• AI inventory: AI inventory is the authoritative record of which AI systems are in use, who owns them, what data they can reach, and why they exist. It is a governance control because without a complete inventory, approval, review, and accountability processes cannot be reliably enforced.
• Transparency obligation: A transparency obligation is a requirement to tell users when they are interacting with AI and to document how the system operates. It turns AI use into an auditable disclosure problem, which means the organisation must be able to prove what was told, to whom, and when.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Lasso Security: Achieving Compliance with AI TRiSM, the EU AI Act and US Executive Order on AI. Read the original.