다가오는 AI 규제: 해외에 판매하는 태국 기업은 무엇을 준비해야 할까

핵심 요약

해외 고객은 법으로 의무화되기 전부터 AI를 어떻게 쓰는지 묻는 설문지를 보내오기 시작할 것입니다.
필요한 것은 문서 더미보다, 처음부터 작업 증거를 스스로 기록하는 시스템입니다.
법 조항 해석은 법률 자문가가 할 일입니다. 저희가 도울 수 있는 부분은 시스템이 실제로 증거를 남기게 만드는 것입니다.

1. 고객이 묻기 전에 태국 기업이 먼저 챙겨야 하는 이유

법보다 먼저 오는 것은 대개 큰 고객사의 설문지입니다. AI를 어디에 쓰는지, 고객 데이터가 어디로 보내지는지, 결과는 누가 검토하는지 묻습니다. 일주일 안에 답하지 못하는 회사는 모르는 사이에 거래를 놓치는 경우가 많습니다.

규칙은 개발자가 어디에 있는지만으로 정해지지 않고, 시장과 영향에 따라 적용될 수 있습니다. 유럽의 기업 고객은 규정 시행일 전에 공급망(Supply Chain)으로 설문지와 계약 조건을 내려보낼 것입니다. 시스템 목록과 문서가 없는 회사는 제품이 좋아도 거래를 잃을 수 있습니다.

EU AI법(EU AI Act) 말고도 태국 개인정보보호법(PDPA), 소비자보호법, 지식재산권 법, 해당 산업의 규정이 있습니다. 활용 사례(Use Case)마다 따로 분석해야 합니다. "우리는 API를 쓰는 사용자일 뿐"이라며 의무가 없다고 여겨서는 안 됩니다.

주의할 점 이 글은 사업을 준비하기 위한 틀을 제시합니다. 법과 일정은 바뀔 수 있으니, 결정하기 전에 법률 자문가에게 실제 제품, 시장, 역할, 계약을 검토받으십시오.

2. 제품 계획에 넣어야 할 일정

다행히 준비해야 할 것의 대부분은 어차피 기업이 해야 하는 일입니다. 데이터가 어디에 있는지, 누가 접근할 수 있는지, 시스템이 잘못 판단하면 어떻게 되돌릴지 아는 것 같은 일입니다.

역할에 따라 규정상 의무가 다르므로, 회사가 개발자인지 사용자인지 유통업자인지 먼저 파악합니다.

EU의 공식 자료에 따르면 이 규정은 단계적으로 적용됩니다. 투명성 요건과 집행의 대부분은 2026년에 시작됩니다. 부속서 III(Annex III)에 있는 일부 고위험(High-risk) 시스템의 요건은 2027년 말로, 규제 대상 제품에 내장된 일부 고위험 AI의 요건은 2028년으로 예정되어 있습니다.

기한까지 기다려서는 안 됩니다. 데이터 거버넌스(Data Governance), 품질 관리(Quality Management), 기술 문서(Technical Documentation), 모니터링을 갖추는 데 시간이 걸리기 때문입니다. 특히 판매 주기가 긴 제품이라면 고객이 준비 상태(Readiness)를 미리 요구할 수 있습니다.

기간	기업이 할 일
지금~2026년	시스템 목록, AI 리터러시, 투명성, 계약
2027년	고위험 분류, 증거, 품질경영시스템(QMS), 공급업체 준비 상태
2028년	제품 규정 준수, 모니터링, 적용 범위에 따른 감사

3. 회사가 제공자(Provider)인지, 배포자(Deployer)인지, 중간 유통자인지 먼저 파악하기

의무는 역할에 따라 다릅니다. 자기 이름으로 시스템을 만드는 회사는 제공자가 될 수 있고, 업무 과정에서 시스템을 쓰는 회사는 배포자입니다. 수입업자와 유통업자에게도 고유한 의무가 있을 수 있습니다. 시스템을 크게 고치거나 의도된 목적(Intended Purpose)을 바꾸면 역할이 달라질 수 있으므로, 공급망 전체에 걸쳐 계약 관계도(Contract Map)를 그려 두어야 합니다.

시스템 안에 들어간 규정 준수 워크플로가 일을 늘리지 않고 증거를 알아서 모읍니다.

활용 사례 목록(Use-case Inventory)을 만들어 목적, 영향을 받는 사람, 의사결정 과정, 데이터, 모델, 시장, 사람의 감독(Human Oversight)을 기록하십시오. 그다음 법무팀이 분류하게 합니다. 기술 이름만 보고 위험도를 분류해서는 안 됩니다. 같은 시스템이라도 마케팅에 쓸 때와 직원 채용 심사에 쓸 때의 위험은 다를 수 있습니다.

4. 어떤 등급으로 분류되든 만들어 두어야 할 증거

승인된 목적과 제약 사항
데이터 출처, 권리, 품질, 보존 기간
모델과 버전, 공급업체, 변경 이력
그룹별, 위험 사례별 평가
사람의 감독과 중지·수정 권한
로그, 사고, 민원, 시정 조치
사용자 안내와, 해당하는 경우 AI 생성 콘텐츠라는 고지

개발팀 참고 · 기술 세부 사항

Documentation as Code로 Evidence를 Release와 연결하고, 1년에 한 번 몰아서 문서를 뒤늦게 쓰지 않습니다. 모델, Knowledge, Intended Use를 바꿀 때마다 영향을 평가하고 Decision Record를 남겨야 합니다.

5. 공급업체 계약으로 가동률 SLA와 함께 증거도 받아 내기

개발팀 참고 · 기술 세부 사항

Training/Data Policy, Security, Model Change, Evaluation, Subprocessor, Location, Incident Notification, Exit/Deletion에 관한 정보를 요청합니다. 회사가 의무를 다하는 데 필요한 문서를 받을 권리를 계약에 명시하십시오. Vendor가 정보를 주지 않으면 회사는 자사 제품의 Compliance를 증명하지 못할 수 있습니다.

개발팀 참고 · 기술 세부 사항

영향도에 따라 Supplier Tier를 나눕니다. 사내 초안 작성에 쓰는 모델과 High-risk Product 안에 들어간 모델은 Due Diligence 수준이 달라야 합니다. Vendor가 조건을 바꾸거나 요건을 충족하지 못할 때에 대비해 Model Replacement Plan을 세워 둡니다.

6. 투명성은 UX와 업무 절차 안에 있어야 합니다

맥락에 맞게, 사용자가 AI와 대화하고 있으면 그 사실을 알리고 AI가 다루는 범위와 사람에게 연락하는 방법을 설명하십시오. 영향이 큰 결정이라면 사용한 데이터를 보여 주고, 해당하는 경우 이의를 제기하거나 재검토를 요청할 권리도 안내합니다. 면책 문구를 긴 약관 속에 숨기지 마십시오.

합성 콘텐츠에는 위험도에 따라 출처 정보(Provenance)를 붙이고 승인을 거치게 해야 합니다. 이후 여러 유통 경로(downstream)를 거쳐도 사라지지 않는 라벨과 메타데이터를 만드십시오. 직원이 AI에 지나치게 의존하지 않도록 교육하고, 고객에게 솔직하게 설명할 수 있는 안내 스크립트도 준비합니다.

규정 준수도 판매 포인트입니다 기업 고객은 안심을 삽니다. 어떤 에이전트가 어떤 데이터를 쓰는지, 누가 책임지는지, 사고가 생기면 어떻게 하는지 답할 수 있다면 보안·법무 검토 기간이 줄고, 데모밖에 보여 줄 것이 없는 경쟁사와 차별화됩니다.

7. 병목이 되지 않는 컴플라이언스 프로그램 만들기

개발팀 참고 · 기술 세부 사항

Risk-tier Workflow를 씁니다: Low-risk는 Self-assessment, Medium은 Data/Security 팀의 Review, High-risk는 Cross-functional Assessment. Template, Approved Pattern, Sandbox를 만들어 팀이 Guardrail 안에서 빠르게 움직이게 합니다. Legal은 Go-live 직전 마지막 날에 들어오면 늦고, Design 단계부터 참여해야 합니다.

개발팀 참고 · 기술 세부 사항

AI Governance Committee는 적당한 규모로 꾸리고, 모든 Prompt를 승인하는 대신 Policy와 예외 사항에 집중하게 합니다. AI Register, Owner, Review Date, Incident/Evidence Dashboard를 갖추고, 실제로 지켜지는지는 Sampling으로 점검합니다.

8. 법 조항이 모두 명확해지기를 기다리지 않고 오늘 할 수 있는 일

모든 AI 시스템과 그 시스템이 닿는 시장을 대장에 올립니다.
책임자(Owner), 의도된 용도(Intended Use), 초기 위험도를 정합니다.
데이터·모델 계보(Lineage)와 버전 기록을 만듭니다.
사람의 감독, 사고 대응, 민원 처리 절차를 정합니다.
구매 계약과 공급업체 계약에 AI 조항을 넣습니다.
주요 활용 사례와 시장 진출 로드맵을 법무팀이 검토하게 합니다.

요약: 해외에 판매하는 태국 기업은 고객이나 규정이 요구하기 전에 증거와 거버넌스를 준비해야 합니다. 시스템 목록, 분류, 계보, 평가, 사람의 감독은 법이 어떻게 바뀌든 쓸모 있는 기반입니다. 목표로 삼을 것은 체크리스트 통과용 문서보다, 설명하고 통제하고 고칠 수 있는 시스템입니다.

공식 참고 자료European Commission: EU AI Act implementation timeline
European Commission: Navigating the AI Act

DNA MAKER · SOLUTION BLUEPRINT

고객과 감사인에게 답할 수 있는 작업 증거를 첫날부터 쌓습니다

법적 요건을 해석하는 일은 회사의 법률 자문가와 컴플라이언스 팀이 맡을 일이고, 소프트웨어 회사가 대신할 일이 아닙니다. DNA Maker가 할 수 있는 일은 팀이 이미 정리한 요건을 시스템이 자동으로 하는 일로 바꾸는 것입니다. 어떤 데이터로 결정을 내렸는지 기록하고, 그 시점에 쓰인 모델과 규칙의 버전을 보관하고, 동의를 받아 기록하고, 사용자에게 자동화 시스템과 대화 중이라는 사실을 알리는 일 같은 것입니다. 이런 기록은 평소 업무에서 자연스럽게 남아야 합니다. 나중에 따로 쫓아다니며 모아야 하는 추가 업무가 되어서는 안 됩니다.

시스템이 자동으로 남겨야 할 기록

저희가 설계하는 시스템에는 보통 핵심 로직과 분리된 기록 계층이 있어서, 모델이나 서비스 제공업체를 바꿔도 증거가 끊기지 않습니다. 컴플라이언스 팀이 개발팀을 기다리지 않고 직접 보고서를 뽑을 수 있는 대시보드가 있고, 무언가를 바꿀 때마다 다시 돌려서 품질이 떨어지지 않았음을 증명하는 테스트 세트도 있습니다. 해외 고객이 AI 사용에 관한 설문지를 보내오기 시작했는데 여러 팀에 일일이 물어봐야 답할 수 있다면, 바로 그 지점에서 시스템이 실제로 도움이 됩니다.

SOFTWARE ENGINEERING GLOSSARY

소프트웨어 엔지니어링 용어집

증거와 사후 검증에 관해 개발팀과 이야기할 때 도움이 되는 용어입니다.

용어	의미	쉬운 예시	개발팀에 물어봐야 할 질문
Traceability	어떤 결과가 어떤 데이터와 규칙에서 나왔는지 되짚어 볼 수 있는 능력	이 요청을 거절할 때 어느 버전의 기준을 썼는지 확인할 수 있습니다.	어디까지 추적할 수 있고, 기록은 얼마나 오래 보관합니까?
Versioning	특정 시점에 무엇을 썼는지 알 수 있도록 모델, 규칙, 문서의 버전을 보관하는 일	지난달에는 시스템이 규칙 버전 3을 썼다고 기록해 둡니다.	석 달 전 결과를 설명해야 한다면 정보가 충분합니까?
Consent	데이터를 수집하거나 쓰기 전에 사용자의 동의를 받고 기록하는 일	고객이 대화 내용 저장에 언제 동의했는지 기록합니다.	동의 사실을 나중에 어떻게 증명할 수 있습니까?
PII	특정 개인을 식별할 수 있어 특별히 관리해야 하는 정보	고객의 이름, 전화번호, 문서 번호	개인정보가 외부의 어떤 시스템으로 보내지고 있습니까?
Model Card	모델을 어디에 쓰는지, 어떤 한계가 있는지, 어떻게 평가했는지 요약한 문서	사용 범위와 쓰면 안 되는 경우를 정리한 요약	지금 쓰는 시스템에 이런 문서가 있습니까?