대부분의 AI 팀은 잘못된 질문으로 컴플라이언스(Compliance, 준수) 작업을 시작합니다:

우리 제품이 EU AI Act를 준수하나요?

합리적으로 들릴 수 있습니다. 하지만 변호사, 컴플라이언스 전문가, 기업 고객 또는 평가 도구는 제품이 실제로 무엇을 하는지 먼저 이해하지 않고서는 이 질문에 책임감 있게 답변할 수 없습니다.

그들은 다음 사항을 알아야 합니다:

• AI 시스템의 의도된 목적은 무엇인가;
• 누가 사용하는가;
• 그 출력물에 의해 누가 영향을 받는가;
• 어떤 결정에 영향을 미치는가;
• 어떤 모델과 벤더(Vendor)가 관여되어 있는가;
• 어떤 데이터를 처리하는가;
• 인간의 검토(Human review)가 어디에 존재하는가;
• 회사가 어떤 증거를 제공할 수 있는가.

이러한 사실들이 없다면, "우리는 준수하고 있는가?"는 아직 법적인 질문이 아닙니다.

그것은 불완전한 제품 발견(Product-discovery) 과제일 뿐입니다.

대규모 컴플라이언스 프로그램을 구축하기 전에, 간결한 AI 시스템 브리프(AI System Brief)를 작성하십시오.

이 기사는 일반적인 정보 제공을 목적으로 하며, 법적 조언이 아닙니다.

컴플라이언스는 제품의 사실로부터 시작됩니다

기업들은 종종 자신들이 "AI 제품"을 보유하고 있다고 설명합니다.

실제로 하나의 SaaS 애플리케이션에는 여러 개의 별개 AI 기반 시스템 또는 기능이 포함될 수 있습니다:

• 고객 대응 챗봇(Chatbot);
• 요약 도구(Summarisation tool);
• 추천 엔진(Recommendation engine);
• 사기 위험 점수(Fraud-risk score);
• 문서 분류기(Document classifier);
• 후보자 순위 지정 기능(Candidate-ranking feature);
• 내부 지원 어시스턴트(Internal support assistant);
• 레코드를 업데이트하거나 메시지를 보낼 수 있는 에이전트(Agent).

이러한 기능들은 서로 다른 목적, 사용자, 리스크 및 기술적 의존성을 가질 수 있습니다.

제품 관련 질문에 답하는 챗봇은 채용을 위해 지원자를 순위 매기는 시스템과 반드시 동일한 방식으로 분석되는 것은 아닙니다.

두 기능이 동일한 기반 모델(Underlying model)을 사용하더라도, 그 법적 및 운영적 맥락은 매우 다를 수 있습니다.

따라서 첫 번째 유용한 단계는 회사 전체에 하나의 컴플라이언스 라벨을 부여하는 것이 아닙니다.

그것은 제품 내부의 개별 AI 시스템 (AI systems)을 식별하는 것입니다.

의도된 목적 (Intended purpose)부터 시작하세요

의도된 목적은 AI 시스템 브리프 (AI system brief)에서 가장 중요한 항목 중 하나입니다.

다음과 같은 모호한 설명은 피하십시오:

우리는 생산성을 향상하기 위해 AI를 사용합니다.

이는 시스템이 실제로 무엇을 하는지 설명하지 못합니다.

더 나은 설명은 다음과 같습니다:

이 시스템은 유입되는 고객 지원 티켓 (customer-support tickets)을 분석하고, 제안된 카테고리를 할당하며, 지원 상담사가 검토할 수 있도록 답변 초안을 작성합니다.

이 문장은 몇 가지 중요한 사실을 드러냅니다:

• 시스템이 고객과의 커뮤니케이션을 분석함;
• 티켓을 분류함;
• 텍스트를 생성함;
• 사람이 출력물을 검토할 것으로 예상됨;
• 결과물이 비즈니스 프로세스를 독립적으로 완료하기보다는 지원함.

다음과 비교해 보십시오:

이 시스템은 입사 지원서를 분석하고, 각 후보자에게 적합성 점수를 할당하며, 어떤 후보자를 채용 담당자에게 먼저 보여줄지 결정합니다.

두 제품 모두 "AI 어시스턴트 (AI assistants)"라고 설명될 수 있습니다.

하지만 두 번째 시스템은 자연인 (natural persons)이 연루된 고용 관련 프로세스에 영향을 미칩니다.

"AI 어시스턴트"라는 라벨은 우리에게 거의 아무것도 알려주지 않습니다.

의도된 목적은 훨씬 더 많은 것을 알려줍니다.

AI 법 (AI Act)의 공식 제6조 분류 규칙 (Article 6 classification rules)은 시스템의 의도된 목적, 사용 사례 (use case), 그리고 출력물이 의사 결정에 실질적인 영향을 미치는지 여부에 초점을 맞춥니다.

관련된 사람들 식별하기

AI 시스템 브리프는 최소 세 그룹을 구분해야 합니다.

사용자 (Users)

시스템을 직접 운영하거나 상호작용하는 사람들입니다.

예시:

• 지원 상담사 (support agents);
• 채용 담당자 (recruiters);
• 관리자 (administrators);
• 소비자 (consumers);
• 개발자 (developers).

영향을 받는 사람들 (Affected people)

출력물에 의해 기회, 접근성, 처우 또는 경험이 영향을 받을 수 있는 사람들입니다.

예시:

• 입사 지원자 (job applicants);
• 대출자 (borrowers);
• 학생 (students);
• 환자 (patients);
• 직원 (employees);
• 고객 (customers).

책임 있는 사람들 (Responsible people)

출력물을 검토하고, 사고를 처리하며, 변경 사항을 승인하거나, 불만 사항에 대응할 것으로 기대되는 사람들입니다.

이 그룹들은 항상 동일하지는 않습니다.

채용 담당자(recruiter)는 순위 산정 도구를 사용할 수 있고, 구직자(job applicants)는 그 영향을 받을 수 있으며, 인사 관리자(HR manager)는 감독 책임을 질 수 있습니다.

이러한 관계를 문서화하면 향후 리스크 및 거버넌스(governance) 논의를 훨씬 더 구체적으로 진행할 수 있습니다.

출력물이 무엇에 영향을 미치는지 기록하세요

모델이 무엇을 생성하는지 기술하는 데서 멈추지 마세요.

그 다음에 어떤 일이 일어나는지를 문서화하세요.

예를 들어:

시스템은 0에서 100 사이의 점수를 생성합니다.

이것은 기술적으로는 정확하지만 불완전합니다.

더 유용한 설명은 다음과 같습니다:

해당 점수는 지원서가 검토되는 순서를 결정합니다. 임계값(threshold) 미만의 후보자가 자동으로 탈락하는 것은 아니지만, 현재 워크플로(workflow) 하에서 채용 담당자가 이들을 검토하는 경우는 드뭅니다.

두 번째 버전은 시스템의 실질적인 영향력을 설명합니다.

다음 질문을 던져보세요:

• 출력물이 정보 제공용인가요?
• 추천(recommendation)인가요?
• 사람의 순위를 매기거나 점수를 부여하나요?
• 자격 요건(eligibility)을 결정하나요?
• 자동으로 동작을 트리거(trigger)하나요?
• 사람이 이를 무효화(override)할 수 있나요?
• 검토자가 이를 평가할 수 있는 충분한 시간과 맥락(context)을 현실적으로 가지고 있나요?
• 모델이 불확실할 때는 어떤 일이 발생하나요?

시스템이 결정에 중대한 실질적 영향을 미치더라도

잠재적 역할:
고객 대면 AI 시스템의 제공자

...

문서화된 불확실성은 설명되지 않은 녹색 체크 표시보다 더 유용합니다.

기술적 의존성(Technical dependencies) 매핑하기

대부분의 AI SaaS 제품은 여러 외부 구성 요소에 의존합니다.

시스템 브리프(System brief)는 다음 사항을 식별해야 합니다:

• 모델 제공자 (model providers);
• 호스팅 제공자 (hosting providers);
• 벡터 데이터베이스 (vector databases);
• 분석 도구 (analytics tools);
• 관측성 플랫폼 (observability platforms);
• 데이터 레이블링 서비스 (data-labelling services);
• 문서 처리 서비스 (document-processing services);
• 음성 또는 이미지 API (speech or image APIs);
• 오픈 소스 모델 및 라이브러리 (open-source models and libraries).

각 의존성에 대해 다음을 기록하십시오:

• 무엇을 제공하는가;
• 어떤 데이터가 전송되는가;
• 처리가 어디에서 발생하는가;
• 데이터가 얼마나 오래 보관되는가;
• 고객 데이터가 학습에 사용될 수 있는가;
• 모델 업데이트가 어떻게 전달되는가;
• 어떤 기술 문서(technical documentation)를 사용할 수 있는가;
• 벤더가 모델을 변경하거나 중단할 경우 어떤 일이 발생하는가.

유명한 모델 제공자를 사용한다고 해서 귀하의 제품 자체에 대한 질문이 해결되는 것은 아닙니다.

귀하의 애플리케이션은 여전히 자체적인 다음 요소들을 가지고 있습니다:

• 의도된 목적 (intended purpose);
• 인터페이스 (interface);
• 통합 (integrations);
• 사용자 (users);
• 데이터 흐름 (data flows);
• 안전 장치 (safeguards);
• 장애 모드 (failure modes).

전체 시스템은 고객과 영향을 받는 사람들이 경험하는 실체입니다.

데이터 흐름(Data flow) 포착하기

유용한 데이터 흐름 설명이 반드시 복잡한 아키텍처 다이어그램(architecture diagram)으로 시작할 필요는 없습니다.

간단한 표만으로도 충분할 수 있습니다:

목표는 숨겨진 처리를 가시화하는 것입니다.

이는 종종 다음과 같은 중요한 질문들을 드러냅니다:

• 모델 요청에 개인 정보가 포함되어 있는가?
• 프롬프트(prompts)가 외부 제공자에 의해 저장되는가?
• 민감한 필드를 제거할 수 있는가?
• 로그(logs)에 너무 많은 직원이 접근할 수 있는가?
• 삭제가 모든 벤더에 적용되는가?
• 회사가 어떤 모델이 출력을 생성했는지 재현할 수 있는가?
• 회사가 사고 발생 당시 어떤 시스템 버전이 활성화되어 있었는지 식별할 수 있는가?

이러한 질문들은 특정 AI 법(AI Act) 의무 사항이 확인되기 전이라도 개인정보 보호(Privacy), 보안(Security), 조달(Procurement), 디버깅(Debugging) 및 사고 대응(Incident response) 측면에서 매우 중요합니다.

인간의 감독(Human oversight)을 정직하게 문서화하세요

많은 제품 설명에는 다음과 같은 문구가 포함되어 있습니다:

인간이 항상 루프 안에 있습니다 (A human is always in the loop).

이러한 진술은 종종 너무 모호하여 실질적인 도움이 되지 않습니다.

시스템 브리프(System brief)는 다음 질문에 답할 수 있어야 합니다:

• 책임 있는 인간은 누구인가?
• 어느 시점에 출력을 검토하는가?
• 그들은 어떤 정보를 보는가?
• 결과를 거부하거나 수정할 수 있는가?
• 실패를 식별하도록 교육받았는가?
• 오버라이드(Overrides)가 기록되는가?
• 업무량이 많을 때는 어떻게 되는가?
• 영향을 받은 사람이 인간의 검토를 요청할 수 있는가?
• 에스컬레이션(Escalations)은 누가 처리하는가?

확인 버튼 하나가 자동으로 의미 있는 감독을 만들어내지는 않습니다.

만약 직원들이 평가를 위한 충분한 맥락 없이 시간당 수백 개의 출력을 승인한다면, 형식적인 인간의 존재가 실제 워크플로우(Workflow)를 반영하지 못할 수 있습니다.

이론적으로 인터페이스가 허용하는 것뿐만 아니라, 실제 현장에서 어떤 일이 일어나는지를 기술하십시오.

고위험(High-risk) AI 시스템의 경우, 인간의 감독(Human-oversight) 요구 사항은 제14조에서 구체적으로 다룹니다.

가벼운 증거 패키지(Evidence pack)를 구축하세요

준수(Compliance)란 단순히 통제 장치가 존재한다고 말하는 것만이 아닙니다.

그것을 실제로 보여줄 수 있어야 한다는 뜻입니다.

가벼운 증거 패키지에는 다음이 포함될 수 있습니다:

• AI 시스템 인벤토리(Inventory)
• 각 시스템에 대한 한 페이지 분량의 브리프(Brief)
• 모델 및 벤더(Vendor) 인벤토리
• 의도된 목적(Intended-purpose)에 대한 설명
• 데이터 흐름(Data-flow) 설명
• 사용자 고지 사항(User disclosures)
• 인간의 감독 절차
• 위험 및 한계 사항 기록
• 테스트 기록
• 로깅(Logging) 방식
• 사고 및 에스컬레이션 프로세스
• 법률 고문에게 전달할 미결 질문 사항

모든 항목이 모든 AI 시스템에 대한 보편적인 법적 요구 사항은 아닙니다.

그 차이를 구분하는 것이 중요합니다.

AI 법은 고위험 시스템에 대해 다음과 같은 특정 요구 사항을 설정합니다:

• risk management;
• technical documentation;
• record-keeping;
• human oversight;
• accuracy, robustness, and cybersecurity.

저위험 제품이라도 기업의 조달(procurement), 보안, 고객 신뢰 확보, 디버깅 또는 미래 대비에 도움이 되기 때문에 유사한 자료를 유지할 수 있습니다.

준비 문서(evidence pack)의 각 항목을 다음 중 하나로 분류하세요:

• 확정된 법적 요구 사항 (Confirmed legal requirement)
• 권장되는 준비 관행 (Recommended readiness practice)
• 고객 또는 조달 요구 사항 (Customer or procurement requirement)
• 법적 확인 필요 (Requires legal confirmation)

이렇게 해야만 준비 문서가 법률 의견인 것처럼 오해되는 것을 방지할 수 있습니다.

제품 수준의 투명성 대비하기

Article 50에는 사람과 직접 상호작용하는 일부 시스템이나 콘텐츠를 생성하거나 조작하는 일부 시스템을 포함하여 특정 AI 시스템에 대한 투명성 의무(transparency obligations)가 명시되어 있습니다.

위원회(Commission)의 공식 AI Act 구현 로드맵 (AI Act implementation timeline)에 따르면, 이러한 투명성 의무는 2026년 8월 2일부터 적용됩니다.

제품 팀의 경우, 준비 과정에는 다음과 같은 질문들이 포함될 수 있습니다:

• 사용자가 AI와 상호작용하고 있다는 것을 알고 있는가?
• 고지(disclosure)는 첫 번째 상호작용 전 또는 도중에 표시되는가?
• 모바일 환경에서 명확한가?
• 생성된 콘텐츠는 필요한 곳에 라벨링되어 있는가?
• 인터페이스가 인간의 개입을 과장하고 있는가?
• 워크플로우가 변경될 때도 고지가 정확하게 유지되는가?
• 정보가 접근 가능하고 이해하기 쉬운가?

이것은 단순한 정책 문서 작업이 아닙니다.

이는 제품 설계(product-design) 작업입니다.

긴 서비스 약관(terms-of-service) 페이지 속에 숨겨진 공개 사항은 사용자가 상호작용(interaction) 중에 실제로 경험하는 내용을 반영하지 못할 수도 있습니다.

알려진 불확실성(uncertainty) 포함하기

AI 시스템 브리프(AI System Brief)는 모든 분류(classification) 질문이 이미 해결된 것처럼 가장해서는 안 됩니다.

유용한 섹션은 다음과 같은 형태일 수 있습니다:

잠재적 분류(Potential classification):
가능한 Annex III 고위험(high-risk) 사용 사례

...

이렇게 하면 변호사나 전문가가 검토할 수 있는 구체적인 내용을 제공할 수 있습니다.