EU AI Act handbook maps compliance duties before penalties hit

At a glance

What this is: Saidot’s AI Act Handbook is a compliance primer on the EU AI Act, highlighting scope, obligations, timelines, penalties, exemptions, and practical preparation steps for organisations.

Why it matters: It matters because AI governance teams need a clear route from regulatory text to inventory, classification, literacy, and audit readiness before high-risk obligations start to bite.

Context

The EU AI Act creates a governance problem before it creates a tooling problem: organisations have to identify which systems fall within scope, classify risk correctly, and assign obligations to the right internal owners. For many programmes, the gap is not whether they have AI activity, but whether they have a defensible inventory and a repeatable way to prove control.

This is especially relevant where AI systems touch human identity, decision-making, or regulated processes, because compliance depends on lifecycle control rather than one-off policy statements. Saidot’s handbook frames that transition from awareness to implementation, which is a common weak point in AI governance programmes rather than an exceptional one.

Key questions

Q: How should security teams structure EU AI Act compliance for AI systems?

A: Start with a complete AI inventory, then classify each system by risk tier and map the required controls to that tier. Use existing privacy and security processes, including DPIAs, access reviews, and documentation, as the backbone for AI governance. The goal is to make compliance continuous, not a one-time legal exercise.

Q: Why do AI systems with weak inventory and impact assessments create more governance risk for organisations?

A: AI governance fails when teams cannot see what tools are in use, what data they process, or how decisions affect people. Without a complete inventory and credible impact assessments, leaders cannot judge scope, assign accountability, or prove control operation to auditors. That creates blind spots in compliance, privacy, and third-party oversight.

Q: What breaks when AI literacy training is separated from the workflow?

A: The organisation loses evidence that guidance was received at the moment risk occurred. Annual training can show completion, but it cannot prove that an employee saw the right warning before pasting sensitive data into an AI tool or approving a risky integration.

Q: What should privacy and risk teams do first with AI governance changes?

A: They should build a current inventory of AI systems, classify each use case, and connect every system to a business owner and evidence source. That gives the programme a control baseline that can absorb future legal and technical changes.

Technical breakdown

How EU AI Act obligations map to system type and role

The AI Act is structured around what the system does and who places it on the market or uses it, not just whether it is called AI. That means providers, deployers, and GPAI actors can face different obligations even when they use similar technical stacks. For governance teams, the operational challenge is assigning obligations by role, then linking each AI system to the correct risk classification and control set. Without that mapping, compliance becomes inconsistent across business units and procurement paths.

Practical implication: Build a role-to-system obligation map before policy rollout so compliance evidence matches how AI is actually deployed.

Why AI literacy and inventory control matter before enforcement

AI literacy is not a training slogan. In regulatory terms, it is a governance prerequisite because people who design, deploy, approve, or supervise AI need enough understanding to apply controls consistently. That depends on an inventory of systems, use cases, owners, and risk classes. If the inventory is incomplete, literacy programmes cannot be targeted and control testing cannot be reliably scoped. The result is compliance theatre rather than auditable governance.

Practical implication: Create and maintain a system inventory that links each AI use case to owner, risk class, and required training.

What high-risk classification changes in practice

High-risk designation changes AI governance from policy guidance to control enforcement. Organisations need documented processes for oversight, testing, incident handling, recordkeeping, and post-deployment monitoring that can survive scrutiny. The practical issue is that many teams treat AI review as a design-time approval, when the regulation expects lifecycle governance. That includes repeatable evidence that controls were applied, not just that the right policy existed. For identity and access teams, this often intersects with approval workflows, privileged access, and audit trails around who can change model behaviour or deployment settings.

Practical implication: Treat high-risk AI as a lifecycle control problem and require evidence for approval, monitoring, and change management.

NHI Mgmt Group analysis

AI Act readiness is an inventory problem before it is a legal problem. Organisations cannot credibly classify risk, assign duties, or evidence compliance if they do not know which AI systems exist, who owns them, and where they are used. That makes discovery and classification the foundation of any defensible AI governance programme. Practitioners should treat inventory quality as the first compliance control, not an administrative task.

AI literacy will fail if it is treated as generic training. The regulation expects people to understand the AI they operate, which means role-specific knowledge for deployers, approvers, reviewers, and technical owners. A broad awareness campaign is not enough when high-risk decisions require repeatable judgement and audit evidence. The practical conclusion is that literacy programmes need to be mapped to actual responsibility, not delivered as a one-size-fits-all module.

High-risk AI governance now resembles lifecycle control, not annual policy review. The obligations implied by the handbook point toward monitoring, traceability, and change control across the full operating life of a system. That is a familiar pattern for IAM and GRC teams, but it is still new for many AI programmes. Where AI can influence identity, access, or regulated decisions, governance must prove control over change, not just approval at launch.

Agentic and embedded AI will force identity teams into the centre of AI compliance. Once AI systems can trigger actions, access data, or interact with other services, the governance question becomes who or what is authorised to act. That is where AI policy intersects with IAM, PAM, and NHI control design. The practitioner takeaway is that AI Act preparation should be built alongside identity governance, not kept separate from it.

What this signals

AI Act readiness will separate organisations that can prove control from those that can only describe policy. The near-term pressure is not just legal interpretation but operational evidence, because regulators will care about traceability, ownership, and repeatable governance outcomes. Identity, access, and change-control teams will be pulled into AI oversight wherever systems can influence decisions or trigger actions.

AI governance debt will grow fastest where inventory and ownership are unclear. Once AI use is spread across departments, the hardest part of compliance is no longer drafting policy, but finding every model, classifying its risk, and keeping the evidence current. Practitioners should expect audit readiness to depend on the same disciplines used in IAM and GRC: assignment, review, and lifecycle control.

For practitioners

• Define the AI system inventory Create a living register of models, applications, and use cases, then assign owners, risk classes, and deployment context to each record.
• Map obligations by role Separate provider, deployer, and GPAI responsibilities so legal, security, product, and engineering teams know which controls they own.
• Build evidence for audit readiness Capture approval records, monitoring outputs, change logs, and incident handling artefacts so compliance can be demonstrated, not just claimed.
• Target AI literacy to job functions Train the people who approve, deploy, and supervise AI on the specific risk class and control expectations relevant to their role.

Key takeaways

• The AI Act turns AI governance into a classification, ownership, and evidence problem rather than a simple policy exercise.
• Organisations with incomplete AI inventories will struggle to assign obligations, target literacy, and prove audit readiness.
• Lifecycle controls, not launch approvals alone, are what will matter once high-risk AI obligations start to apply.

Key terms

• AI System Inventory: A governed record of every AI system, its owner, purpose, data scope, and risk tier. In practice, it is the control register that lets security, compliance, and audit teams decide which obligations apply and which evidence must be retained.
• AI Literacy: The ability to understand what AI can do, where it fits, and where it creates operational risk. For IT teams, it means enough practical knowledge to evaluate deployment choices, support AI-enabled services, and avoid treating automation as magic.
• High-Risk AI: High-Risk AI is an artificial intelligence system whose decisions can materially affect people, operations, or security. It typically includes models used for hiring, access decisions, fraud detection, critical workflows, or autonomous actions. Such systems require stronger governance, testing, monitoring, human oversight, and controls for data quality, bias, explainability, and misuse.
• GPAI Model: A general-purpose AI model is a foundation model designed to support many downstream use cases rather than a single narrow task. Under the EU AI Act, GPAI models carry their own governance, disclosure, and compliance expectations. Their broad reuse potential makes oversight especially important when they are embedded into customer-facing or regulated workflows.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security for practitioners who need to connect access control to emerging AI risks. It helps security and governance teams build the identity foundation that AI oversight increasingly depends on.