IM Engineer Study Notes
← Back to list
AI & Data
#EU AI Act#인공지능 규제#AI 거버넌스#위험기반#고위험 AI#GPAI#투명성
Last updated · 2026-09-28

EU AI Act: Risk Classification and Compliance Design

1. Overview

A. Definition

The EU AI Act is a risk-based regulatory framework that classifies AI systems by context and impact and assigns graduated duties for prohibited practices, transparency, general-purpose AI, and high-risk systems.

The Act is not a blanket ban and it is not one checklist for every model. It considers impact on safety, health, and fundamental rights together with the degree of autonomy. An information-management professional should therefore build an AI inventory and map provider, deployer, owner, operator, and evidence responsibilities. The rules can affect organizations outside the Union when their systems or outputs are supplied to, used in, or affect people in the Union. Scope and exemptions depend on the service, role, research purpose, and other facts, so legal review remains necessary.

2. Risk-based structure

The most useful implementation view is a layered risk structure. Prohibited practices are blocked; limited-risk systems require appropriate transparency; high-risk systems require quality, documentation, logging, human oversight, accuracy, robustness, and cybersecurity controls. General-purpose AI providers have separate duties for documentation, copyright policy, evaluation, and incident reporting.

flowchart TB
  A[Use case and impact analysis] --> B{Risk classification}
  B -->|Prohibited| C[Block provision and use]
  B -->|Transparency| D[Disclose AI interaction and synthetic content]
  B -->|High risk| E[Quality, documentation, and human oversight]
  B -->|GPAI| F[Model documentation, copyright, evaluation]
  B -->|Minimal risk| G[Voluntary and general controls]
  E --> H[Assessment, registration, and monitoring]
  F --> H

“Not high risk” does not mean “no control”. Security, privacy, copyright, bias, and safety controls still apply through other law, contracts, and internal policy. Classification is driven by purpose and context, not merely by model complexity.

3. Roles and lifecycle controls

Provider, deployer, importer, distributor, product manufacturer, and authorized representative roles should be mapped to actual authority and resources. An organization using an external model is not automatically free of responsibility. The contract should define model version changes, documentation, service levels, data processing, incident notice, and termination conditions.

flowchart LR
  P[Provider] --> Q[Documentation, evaluation, quality]
  Q --> R[Importer and distributor]
  R --> U[Deployer and operator]
  U --> V[Users and affected people]
  U --> W[Logs, incidents, complaints]
  W --> X[Correction and provider feedback]
  X --> Q

High-risk lifecycle controls begin with purpose, affected groups, foreseeable misuse, residual risk, and mitigation. Data governance records source, purpose, labels, representativeness, errors, gaps, rights, and retention. Technical documentation must cover architecture, data, training, validation, performance, limitations, risks, and changes. Logging should connect input, output, time, user, model version, policy version, human intervention, and errors while minimizing personal data. Human oversight means a trained operator can understand limits, challenge a result, request explanation, stop the system, and use a fallback process.

4. Compliance architecture

Compliance should be inserted into product engineering rather than isolated in a legal repository. An AI catalog identifies models, data, prompts, tools, and use cases. A risk service classifies impact and roles; a policy engine blocks prohibited functions; a validation gate checks evidence before release. Monitoring collects drift, errors, fairness, security events, and complaints and connects them to incident management.

flowchart TB
  A[AI catalog] --> B[Risk and role assessment]
  B --> C[Policy and prohibited-use guard]
  C --> D[Data and model validation gate]
  D --> E[Approval and conformity evidence]
  E --> F[Controlled release]
  F --> G[Logs, quality, fairness monitoring]
  G --> H{Incident or change}
  H -->|No| G
  H -->|Yes| I[Stop, correct, report, reassess]
  I --> B

5. Comparison and cases

A privacy impact assessment focuses on rights and proportionality in personal-data processing. An information-security management system focuses on assets, threats, and protective controls. An AI impact assessment adds purpose, model performance, fairness, explainability, human oversight, and remedy. Use common identifiers in the AI catalog so the three assessments do not duplicate evidence.

For a recruitment recommender, compare error and recommendation rates across relevant groups, review historical bias, provide human reconsideration, and monitor whether staff actually use the remedy path. For a customer-service generative assistant, restrict answers to an approved knowledge base, disclose the AI interaction, retain model and retrieval versions, and transfer rights or safety questions to a human. A provider update must trigger regression, privacy, dangerous-question, and tool-permission tests because the same prompt can change behavior.

6. Advanced discussion and exam framing

As of September 2026, official European guidance describes a staged application of the Act, with transparency and enforcement activity becoming important from August 2026 and later transition rules for different high-risk categories. Dates and amendments should be checked against the current official text rather than memorized as permanent facts. In an engineering answer, show the sequence: identify purpose and affected stakeholders; classify role and risk; place data, model, software, and organizational controls across the lifecycle; connect evidence and incident response; then discuss trade-offs.

7. Considerations and implications

  1. Assign regulatory monitoring and trace every legal change into requirements, tests, policy, and contracts.
  2. Use risk-based automation so low-impact innovation is not driven into shadow systems while high-impact models receive independent validation.
  3. Treat model, prompt, retrieval index, policy, and supplier updates as change events requiring appropriate re-evaluation.
  4. Evaluate group-level error, remedy, human oversight, privacy, and safety together with average accuracy.
  5. Minimize evidence data through masking, separated identifiers, encryption, access logging, and retention limits.
  6. Test shutdown, rollback, manual fallback, correction, appeal, and business continuity before a serious incident.

References

In one line: EU AI Act readiness means classifying AI use cases by risk and role, then connecting data, model, human oversight, evidence, and incident response across the lifecycle.