EU AI Act 준비 없이 에이전트 워크플로우 (agentic workflows)를 확장하는 것은 50만 달러 이상의 거버넌스 부채를 떠안는 것과 같습니다. 컴플라이언스 아키텍처 (compliance architecture) 구축을 2026년 8월까지 미루는 기술 리더들은 2025년 2분기에 미리 설계하여 제거할 수 있었던 강제적인 리팩토링 (refactoring), 감사 마찰 (audit friction), 그리고 운영 리스크 (operational risk)에 직면하게 될 것입니다.

에이전트 워크플로우 (Agentic Workflows)를 확장하기 전 기술 리더가 답해야 할 EU AI Act 질문들

요약 (TL;DR): 2026년 에이전트 워크플로우 (agentic workflows)를 확장하기 전, CTO 및 기술 리더가 답해야 할 EU AI Act 관련 질문들에 대한 실무 가이드입니다.

AI Act는 귀하의 팀이 "에이전트 (agents)"를 사용하는지 묻지 않습니다. 대신 시스템이 무엇을 하는지, 누가 제어하는지, 어떤 리스크를 생성하는지, 그리고 귀하의 운영 모델 (operating model)이 이를 관리할 만큼 충분히 강력한지를 묻습니다.

많은 팀이 타이밍 실수를 저지르려 하고 있습니다. 그들은 EU AI Act가 모든 것에 대해 이미 완전히 "시행"되었거나, 혹은 엔지니어링 워크플로우 (engineering workflows)에 영향을 미치기에는 아직 너무 멀리 떨어져 있다고 가정합니다. 둘 다 틀렸습니다.

AI Act는 2024년 8월 1일에 발효되었습니다. 금지된 관행 (Prohibited practices) 및 AI 리터러시 (AI literacy) 의무는 2025년 2월 2일부터 적용되었습니다. 범용 AI (GPAI) 의무는 2025년 8월 2일부터 적용되었습니다. 이 법안은 2026년 8월 2일에 광범위하게 적용되며, 규제 대상 제품에 내장된 AI에 대한 일부 고위험 (high-risk) 규칙은 2027년 8월 2일에 적용됩니다. 유럽 위원회(Commission)의 FAQ에서도 표준 설정이 지연됨에 따라 일부 고위험 규칙의 타이밍을 조정하기 위해 2025년 11월 디지털 옴니버스 (Digital Omnibus) 제안이 검토 중이라고 언급하고 있습니다.

따라서 2026년 4월 기술 리더들에게 실질적인 질문은 관심을 가질지 말지가 아닙니다. 확장을 하기 전에 무엇을 명확히 해야 하는가입니다.

AI Act는 "에이전트 워크플로우 (agentic workflows)"라는 특별한 법적 범주를 생성하지 않습니다. 대신 AI 시스템을 의도된 목적 (intended purpose)과 위험 (risk)에 따라 분류합니다. 이는 코딩 에이전트, 워크플로우 에이전트 또는 멀티 에이전트 설정 (multi-agent setup)이 실제로 수행하는 작업에 따라 매우 다른 준수 (compliance) 위치에 놓일 수 있음을 의미합니다. 만약 워크플로우가 저위험 (low-risk) 수준의 내부 엔지니어링 지원에 머문다면, 준수 부담은 상대적으로 가벼울 수 있습니다. 하지만 동일한 워크플로우가 고용, 필수 서비스 접근, 보험, 신용, 공공 서비스 또는 기타 부속서 III (Annex III) 영역에서 사용된다면, 그 부담은 실질적으로 변화합니다.

올바른 리더십 질문은 "에이전트가 규정을 준수하는가?"가 아닙니다. "우리는 어떤 유스케이스 (use cases)를 확장하고 있는가, 우리는 어떤 역할을 수행하고 있는가, 그리고 그에 따라 어떤 의무가 따르는가?"입니다.

1. 이 워크플로우의 의도된 목적 (intended purpose)은 무엇인가?

이것이 첫 번째 질문인 이유는 AI Act의 분류 로직이 의도된 목적에서 시작되기 때문입니다. 유럽 위원회 (Commission)의 FAQ에 따르면, 고위험 (high-risk) 분류는 AI 시스템이 수행하는 기능과 사용되는 구체적인 목적 및 방식 (modalities)에 따라 결정됩니다. 동일한 모델이나 워크플로우라도 한 맥락에서는 저위험일 수 있고, 다른 맥락에서는 고위험일 수 있습니다. 내부 엔지니어링 어시스턴트는 구직자를 필터링하거나, 신용도를 평가하거나, 의료 서비스 접근을 지원하는 데 사용되는 시스템과는 법적으로 매우 다른 대상입니다.

기술 리더들에게 이는 아키텍처 리뷰 (architecture reviews)를 모델 인벤토리 (model inventory)가 아닌 유스케이스 인벤토리 (use-case inventory)부터 시작해야 함을 의미합니다.

2. 우리는 제공자 (provider), 배포자 (deployer), 또는 둘 다인가?

이것은 법적인 문제처럼 들리지만, 실제로는 운영상의 문제입니다. Commission(위원회)의 AI Act 자료는 고위험 시스템의 제공자 (provider)에 대한 의무, 고위험 시스템의 배포자 (deployer)에 대한 의무, 그리고 GPAI 모델 제공자에 대한 의무를 구분합니다. 고위험 시스템의 제공자 (provider)는 리스크 관리 (risk management), 문서화 (documentation), 추적 가능성 (traceability), 투명성 (transparency), 인간의 감독 (human oversight), 견고성 (robustness), 그리고 적합성 평가 (conformity assessment)와 같은 요구 사항을 처리해야 합니다. 고위험 시스템의 배포자 (deployer)는 지침에 따라 시스템을 사용하고, 인간의 감독을 할당하며, 운영을 모니터링하고, 리스크나 심각한 사고에 대응해야 합니다.

이는 기술 리더가 조직이 단순히 벤더의 시스템을 사용하는 것인지, 이를 실질적으로 수정하는 것인지, 아니면 사실상 자체 시스템을 구축하여 서비스에 투입하는 것인지를 파악해야 함을 의미합니다.

3. 어떤 워크플로우가 금지되거나 명확하게 민감한 범주에 속하는가?

이 질문은 규모를 키운 후가 아니라, 규모를 키우기 전에 중요합니다. Commission은 2025년 2월에 금지된 관행 (prohibited-practices) 가이드를 발표했으며, AI Act가 특정 사용 사례를 수용 불가능한 것으로 분류하는 반면, 다른 사례들은 고위험 (high-risk) 이거나 투명성 규칙의 적용을 받는다고 명시하고 있습니다. 금지 가이드는 수용 불가능한 범주 중에서도 특히 해로운 조작 (harmful manipulation), 사회적 점수 매기기 (social scoring), 그리고 특정 생체 인식 관행 (biometric practices)을 지목합니다.

대부분의 엔지니어링 팀에게 실질적인 시사점은 간단합니다. "내부용"이라고 해서 무관하다고 가정하지 마십시오. 만약 어떤 에이전트 기반 워크플로우 (agentic workflow)가 민감한 의사 결정 지원이나 고위험 도메인 사용으로 넘어간다면, 분류를 조기에 재검토해야 합니다.

4. 워크플로우가 고위험 (high-risk) 인 경우, 법안이 요구하는 기본 사항을 갖추고 있는가?

고위험 요구 사항에 대한 Commission의 개요는 이례적으로 실무적입니다. 고위험 AI 시스템은 리스크 관리 (risk management), 관련 있는 경우 고품질 데이터셋 (high-quality datasets), 추적 가능성을 위한 로깅 (logging), 기술 문서 (technical documentation), 배포자를 위한 충분한 투명성 (transparency), 인간의 감독 (human oversight), 그리고 적절한 수준의 견고성 (robustness), 사이버 보안 (cybersecurity), 정확성 (accuracy)이 필요합니다. 또한 제공자 (provider)는 적합성 평가 (conformity assessment)를 수행하고 라이프사이클 책임 (lifecycle responsibility)을 유지해야 합니다.

기술 리더들에게 이는 시스템 설계 (system design)로 직접 연결됩니다:

• 로깅 아키텍처 (Logging architecture)
• 리뷰 설계 (Review design)
• 문서화 표준 (Documentation standards)
• 테스트 및 평가 (Testing and evaluation)
• 보안 통제 (Security controls)
• 인간 개입 경로 (Human override paths)

이것이 바로 컴플라이언스 (compliance)가 단순한 법적 업무 흐름이 아닌, 아키텍처 (architecture)인 이유입니다.

5. 우리는 실질적인 인간 감독 (human oversight) 모델을 갖추고 있습니까, 아니면 단순히 워크플로우 근처에 사람이 있는 수준입니까?

제14조와 위원회 FAQ (Commission FAQ) 모두 인간 감독이 상징적인 것이 아님을 명확히 하고 있습니다. 감독은 자연인이 사용 중에 시스템을 효과적으로 감독할 수 있도록 설계되어야 하며, 고위험 (high-risk) 시스템의 배포자 (deployers)는 필요한 역량, 교육, 권한 및 지원을 갖춘 사람을 배정해야 합니다.

이는 기술 리더들이 다음과 같은 질문에 답할 수 있어야 함을 의미합니다:

• 누가 출력값 (outputs)을 검토하는가?
• 누가 워크플로우를 중단하거나 무효화 (override)할 수 있는가?
• 예외 상황에 대한 책임은 누구에게 있는가?
• 감독 지점 (oversight point)이 실행 전, 머지 (merge) 전, 또는 배포 (deployment) 후에 발생하는가?

만약 답변이 "아마 누군가가 그것을 보게 될 것입니다"라면, 해당 워크플로우는 준비되지 않은 것입니다.

6. 우리는 나중에 필요할 로그와 문서들을 수집하고 있습니까?

이 법안의 고위험 로직은 추적 가능성 (traceability), 로깅 (logging), 기술 문서 (technical documentation), 그리고 사용 지침 (instructions for use)을 반복적으로 지목합니다. 고위험 요구사항에 대한 위원회의 요약과 제12조에서 제14조의 본문 모두 로그, 배포자 정보, 그리고 인간 감독 지원이 선택 사항이 아닌 시스템 요구사항 (system requirements)의 일부임을 강조합니다.

이를 엔지니어링 실무 (engineering practice)로 번역하면, 여러분은 다음 사항을 알고 있어야 합니다:

• 에이전트 (agent)가 무엇을 수행했는가
• 어떤 입력값 (inputs)과 출력값 (outputs)이 중요했는가
• 어떤 도구 (tools)나 시스템을 접촉했는가
• 어떤 승인 (approvals)이 이루어졌는가
• 검토자가 어떻게 결정 경로 (decision path)를 재구성할 수 있는가

이것이 바로 최고의 AI 개발 스택 (AI dev stack)이 모델 선택이 아닌 리뷰 설계 (review design)에서 시작되어야 하는 이유이기도 합니다.

7. 우리의 직원과 운영자들은 우리가 확장하려는 워크플로우를 수행할 만큼 충분한 AI 리터러시 (AI-literacy)를 갖추고 있습니까?

이것은 이미 적용되고 있기 때문에 가장 과소평가된 의무입니다. 위원회(Commission)의 AI 리터러시 (AI literacy) FAQ에 따르면, 제4조(Article 4)는 AI 시스템의 제공자(providers)와 배포자(deployers)가 기술적 지식, 경험, 교육, 훈련 및 사용 맥락을 고려하여, 직원 및 자신을 대신하여 AI 시스템을 다루는 기타 인원들에게 충분한 수준의 AI 리터러시 (AI literacy)를 보장할 것을 요구합니다. 이는 2025년 2월 2일부터 적용되었습니다.

즉, 기술 리더는 다음과 같은 질문을 던져야 합니다:

• 실제로 이 워크플로우를 운영하거나 감독하는 사람은 누구인가?
• 그들은 시스템의 한계를 이해하고 있는가?
• 검토자(reviewers)들은 무엇을 확인해야 하는지 알고 있는가?
• 관리자들은 자신들이 무엇을 승인하고 있는지 알고 있는가?

이 요구 사항을 벤더(vendor)에게 외주(outsource) 줄 수는 없습니다.

8. 만약 우리가 GPAI 모델에 의존한다면, 지금 벤더에게 무엇을 요구해야 합니까?

AI Act의 GPAI 의무 사항은 이미 2025년 8월 2일부터 적용되었습니다. 위원회(Commission)는 GPAI 모델의 제공자(providers)가 기술 문서(technical documentation)를 준비하고, 저작권 정책(copyright policy)을 시행하며, 학습 콘텐츠의 요약본을 공개해야 한다고 밝히고 있습니다. 또한 위험 완화(risk mitigation), 사고 보고(incident reporting), 사이버 보안(cybersecurity)과 같이 시스템적 위험(systemic risk)이 있는 GPAI 모델에 대해서는 추가적인 의무가 부여됩니다. 위원회는 또한 GPAI 실무 강령(GPAI Code of Practice)을 이에 서명하기로 선택한 제공자들에게 적절한 자발적 도구로 인정합니다.

기술적 구매자(technical buyers)의 입장에서 이는 이제 벤더 실사(vendor due diligence)에 다음 사항이 포함되어야 함을 의미합니다:

• 벤더가 어떤 문서를 제공하는가
• 제공자가 GPAI 강령(GPAI code) 또는 그에 상응하는 규정을 준수하는가
• 어떤 저작권 및 학습 데이터 공개(disclosures)가 존재하는가
• 사고 및 시스템적 위험 이슈가 어떻게 처리되는가

이것은 추상적인 정책이 아닙니다. 이는 조달 위생(procurement hygiene)의 문제입니다.

9. 투명성 의무(transparency obligations)가 우리의 워크플로우 설계에 영향을 미칩니까?

네, 그리고 타이밍이 중요합니다. Commission(유럽 위원회)의 AI Act FAQ에 따르면, Article 50 투명성 의무(transparency obligations)는 챗봇(chatbots)과 딥페이크(deepfakes)를 포함한 특정 대화형 및 생성형 시스템(generative systems)에 적용되며, 2026년 8월 2일부터 적용됩니다. 사람과 직접 상호작용하는 AI 시스템의 제공자(Providers)는 명백한 경우가 아니라면 사용자가 AI와 상호작용하고 있음을 알려야 합니다. 생성형 AI 시스템의 제공자는 출력물을 기계 판독 가능한(machine-readable) 형태로 표시해야 합니다. 딥페이크 시스템의 배포자(Deployers)와 특정 공공 이익 목적의 텍스트 생성 사용 사례 또한 예외 사항을 제외하고는 공개 의무(disclosure obligations)를 가집니다.

기술 리더들에게 이는 만약 에이전트 워크플로우(agentic workflows)가 대중에게 공개되는 콘텐츠, 고객 대면 상호작용 또는 조작된 미디어를 생성한다면, 공개 및 라벨링(labeling)이 나중에 추가되는 것이 아니라 지금 제품 및 워크플로우 설계 단계부터 포함되어야 함을 의미합니다.

10. 우리가 공공 기관이거나 민감한 사용 사례에 해당한다면, 기본권 영향 평가(fundamental rights impact assessment)를 수행해야 합니까?

경우에 따라 그렇습니다. Commission의 FAQ에 따르면, 공법(public law)의 지배를 받는 기관이나 공공 서비스를 제공하는 민간 운영자, 그리고 신용도(creditworthiness) 또는 생명 및 건강 보험 가격 책정/위험 평가를 위해 특정 고위험 시스템을 사용하는 운영자는 첫 사용 전에 기본권 영향 평가(fundamental rights impact assessment)를 수행해야 합니다. 또한 FAQ는 이것이 데이터 보호 영향 평가(data protection impact assessment, DPIA)와 연계될 필요가 있을 수 있다고 언급합니다.

이것이 중요한 이유는 많은 기술 리더들이 여전히 영향 평가를 순수하게 개인정보 보호 팀(privacy-team)의 활동이라고 생각하기 때문입니다. AI Act 하에서, 이는 배포 준비성(deployment readiness)의 일부가 될 수 있습니다.

11. 우리는 표준(standards)을 기다리고 있습니까, 아니면 이미 행동하기에 충분한 정보를 알고 있습니까?

이 지점에서 많은 팀이 망설입니다. 유럽 위원회(Commission)의 AI Act 자료에 따르면, 조화된 표준(harmonized standards)은 여전히 개발 중이며, 이러한 지연으로 인해 2025년 11월의 디지털 옴니버스(Digital Omnibus) 제안서에서는 일부 고위험(high-risk) 애플리케이션의 적용 시점을 표준이나 가이드라인과 같은 지원 조치와 연계하는 방안을 검토하도록 했습니다. 하지만 동일한 공식 자료는 이미 분류(classification), 인간의 감독(human oversight), 문서화(documentation), 로깅(logging), 투명성(transparency), 배포자 의무(deployer obligations), GPAI(범용 AI) 의무(duties), 그리고 AI 리터러시(AI literacy)에 대해 지금 바로 내부 준비를 시작할 만큼 충분한 방향성을 제시하고 있습니다.

따라서 2026년 4월에 취해야 할 올바른 조치는 멈춰 서는 것이 아닙니다. 준비 태세를 강화하는 것입니다.

기술 리더를 위한 실무 프레임워크

에이전트 워크플로우(agentic workflows)를 확장하기 전에, 저는 다음 질문들에 대한 서면 답변을 요구할 것입니다:

• 각 워크플로우의 의도된 목적은 무엇인가?
• 어떤 유스케이스(use case)가 타당하게 고위험(high-risk)이거나 금지된 사항에 해당하는가?
• 우리는 이 시스템에 대해 제공자(provider)인가, 배포자(deployer)인가, 아니면 둘 다인가?
• 현재 어떤 검토 및 인간의 감독(human oversight) 모델이 존재하는가?
• 이의 제기가 있을 경우 어떤 로그(logs)와 문서(documentation)를 생성할 수 있는가?
• 이를 운영하고 감독할 수 있을 만큼 충분히 교육된 사람은 누구인가?
• GPAI 벤더(vendors)에게 계약적 및 운영적으로 요구하는 사항은 무엇인가?
• 2026년 8월 2일까지 어떤 투명성(transparency) 의무가 적용되는가?
• 어떤 배포가 기본권 영향 평가(fundamental rights impact assessment)를 촉발하는가?
• 우리가 거버넌스(governance) 모델보다 더 빠르게 확장하고 있지는 않은가?

이것들은 단순한 법률적 잡학 지식이 아닙니다. 법적 결과가 뒤따르는 시스템 설계(system-design) 질문들입니다.

나의 견해

대부분의 기술 팀에게 가장 먼저 필요한 것은 법률 메모가 아닙니다. 그들에게 필요한 것은 컴플라이언스(compliance, 준수) 형태를 갖춘 아키텍처(architecture)에 대한 논의입니다. First AI Movers는 EU 중소기업(SMEs)이 AI 거버넌스를 운영 워크플로우에 매핑할 수 있도록 도와 규제 리스크를 아키텍처적 규율로 전환하도록 지원합니다.

AI Act는 많은 팀이 어차피 갖추고 있어야 했던 규율을 강제하고 있습니다: 더 명확한 유스케이스 (use-case) 경계, 더 강력한 감독, 더 나은 로그 (logs), 더 엄격한 문서화 (documentation), 더 철저한 벤더 실사 (vendor due diligence), 그리고 실험 (experimentation)과 확장 (scale) 사이의 더 명시적인 구분입니다. 2026년 4월까지는 이미 AI Act의 상당 부분이 발효되며, 2026년 8월 2일부로 적용되는 의무 사항들도 충분히 명확해지기 때문에, 수동적으로 기다리는 것은 잘못된 선택입니다.

핵심 요약 (Key Takeaways)