加州建立 AI 審計員註冊制度,2029 年起未註冊者不得提供法定範圍內的 AI 審計
캘리포니아가 AI 감사인 등록제를 만들었습니다: 2029년부터 미등록 감사는 불법, 엔지니어가 미리 챙길 증거 기록
加州州長於 2026-09-09 簽署 SB 813 和 AB 1405,前者建立獨立驗證機構(IVO)框架,後者要求提供 covered AI audit 的人士及機構註冊。
TL;DR
- 2026년 9월 9일 캘리포니아 주지사가 SB 813과 AB 1405에 서명했습니다. SB 813은 정부가 자격을 주는 독립검증기관(IVO) 틀을, AB 1405는 AI 감사를 하려는 사람과 기관이 주 정부 등록부에 등록해야 한다는 규칙을 만듭니다.
- AB 1405의 핵심은 2029년 1월 1일부터 등록하지 않은 사람이나 기관이 "covered AI audit"를 제공하거나 수행하는 것이 금지된다는 점입니다. 등록을 강제당하는 쪽은 AI를 만드는 회사가 아니라 감사를 하는 쪽입니다. 감사를 받는 것 자체는 의무가 아니라 자발적입니다.
- 감사인에게는 등록 정보 갱신 90일, 감사 보고서와 관련 문서 10년 보관, 광고에 등록번호 표기, 최근 12개월 이해관계 점검 같은 구체적인 숫자가 붙습니다. 이것은 법무팀의 일이기 전에 로그와 저장소 설계 문제입니다.
- 이 글이 쓴 날짜와 조항은 법률사무소 두 곳의 요약을 대조한 것이고, 법안 본문을 직접 읽은 것이 아닙니다. 출처마다 다르게 쓴 부분(적용 범위, 등록부 가동 시점)은 아래 "아직 모르는 것"에 따로 적었습니다. 법률 자문이 아닙니다.
- 11월 16일, 곧 이 글을 쓴 날로부터 14일 뒤에는 주 정부가 현장 상주 검증, 이른바 킬스위치, 확대된 사고 보고에 대한 권고안을 내야 합니다. 법이 아직 요구하지 않는 영역이지만 방향을 가늠할 수 있는 첫 문서가 됩니다.
무엇이 서명되었나요?
두 법안은 2026년 9월 9일에 서명되었고, 9월 18일에는 행정명령 N-9-26이 뒤따랐습니다. 법률사무소 Crowell과 MNK의 정리를 겹쳐 보면 역할은 이렇게 나뉩니다.
| 구분 | 무엇을 하는가 | 의무인가 |
|---|---|---|
| SB 813 | 독립검증기관(IVO)이라는 정부 자격 등급의 틀. 전문성, 방법론, 독립성 요건 | 자발적 상위 자격 |
| AB 1405 | 감사인 등록부와 독립성, 투명성, 신뢰성 기준 | 등록 없이 감사 제공 금지(2029-01-01부터) |
| 행정명령 N-9-26 | 두 법의 이행 일정을 앞당기고, 현장 상주 검증·정부 검증 킬스위치·사고 보고 확대를 검토하라는 지시 | 법이 아니라 행정부 지시 |
IVO 쪽에는 눈에 띄는 설계가 하나 있습니다. 이미 수행한 감사 작업이 실질적으로 비슷하면 IVO 심사에 쓸 수 있지만, 자동 인정이 아니라 갭 분석을 거친다는 것입니다. 감사를 한 번 해 두면 끝이 아니라, 감사 산출물을 "나중에 다른 기준과 대조할 수 있는 형태"로 남겨야 한다는 뜻입니다.
또 하나는 책임과의 관계입니다. 요약에 따르면 AI 해악 소송에서 법원은 감사를 받았다는 사실을 책임 판단에 "관련은 있되 결정적이지는 않다(relevant to, but not conclusive of)" 로 볼 수 있습니다. 감사를 받으면 면책된다는 뜻이 아니라, 받았다는 사실이 증거 하나가 된다는 뜻입니다.
언제 무엇이 오나요?
서명일을 0으로 놓고 날짜를 세 보면 일정이 한눈에 들어옵니다. 표지 그림이 그 결과입니다.
| 날짜 | 서명 후 일수 | 내용 (Crowell 요약 기준) |
|---|---|---|
| 2026-09-18 | 9 | 행정명령 N-9-26 서명 |
| 2026-11-16 | 68 | 주 정부가 현장 상주 검증, 킬스위치, 사고 보고 확대에 대한 권고안 제출 |
| 2027-05-01 | 234 | IVO 신청 요건, 기준, 절차 공표 |
| 2027-12-01 | 448 | 감사인 등록부 설립, 등록 시작 |
| 2029-01-01 | 845 | 등록 의무 시행, 미등록 감사 제공 금지 |
날짜는 아래 계산 스크립트로 직접 확인할 수 있습니다.
from datetime import date
signed = date(2026, 9, 9)
milestones = {
"N-9-26 서명": date(2026, 9, 18),
"권고안 제출": date(2026, 11, 16),
"IVO 기준 공표": date(2027, 5, 1),
"등록부 설립": date(2027, 12, 1),
"미등록 감사 금지": date(2029, 1, 1),
}
for name, d in milestones.items():
print(f"{name}: 서명 후 {(d - signed).days}일")
print("권고안 제출까지 남은 일수:", (date(2026, 11, 16) - date(2026, 11, 2)).days)
출력은 9, 68, 234, 448, 845일이고, 이 글을 쓴 2026년 11월 2일 기준 권고안 제출까지는 14일입니다. 다만 행정명령이 일부 일정을 약 1년 앞당기도록 지시했다고 알려져 있어서, 위 표의 날짜가 앞당김을 반영한 것인지는 확인하지 못했습니다. 일정에 의존하는 결정을 하기 전에는 주 정부 공고를 직접 확인하세요.
"covered AI audit"는 무엇을 뜻하나요?
요약본이 옮긴 정의는 다음과 같습니다.
주법 준수에 필요한 AI 시스템 또는 모델의 내부 통제, 프로세스, 시스템을 평가하기 위해 수행하는 감사
두 가지가 눈에 띕니다. 첫째, 대상은 모델 성능 시험이 아니라 통제와 절차입니다. 벤치마크 점수를 재는 일과, "이 회사의 AI 위험 통제가 법이 요구하는 수준으로 작동하는가"를 확인하는 일은 다른 일이고, 이 법이 건드리는 쪽은 후자입니다. 둘째, 주법 준수라는 전제가 붙어 있습니다. 어떤 주법을 기준으로 삼는지에 따라 등록 대상 서비스의 범위가 달라질 수 있어서, 등록부에도 감사인이 다루는 캘리포니아 법과 규정을 적게 되어 있습니다.
감사인은 등록할 때 무엇을 내야 하나요?
AB 1405의 등록부 내용과 의무를 정리하면 다음과 같습니다.
등록부에 적는 것
- 상호와 연락처
- 감사인이 다루는 캘리포니아 법률과 규정
- 보유한 인증과 인정
- 서비스 설명
- ISO, NIST, 국가 감사 기준을 참조하는 표준 운영 절차
독립성 기준
- 독립성을 해칠 만한 금전, 사업, 고용 관계가 없을 것
- 자기가 이전에 한 작업을 평가하지 않을 것
- 최근 12개월 동안 해당 대상에 중대한 책임을 맡았던 사람을 감사에 배정하지 않을 것
감사 보고서에 들어가는 것
- 범위, 목표, 결과, 개선 조치
- 내부 안전 기준 준수 여부
- 한계와 준수 선언(서명, 날짜 포함)
지속 의무
- 중요한 변경이 생기면 90일 이내 주 정부에 갱신
- 보고서와 관련 문서를 최소 10년 보관
- 모든 광고에 등록번호 표시
집행: 주 정부가 위반을 조사하고, 확인되면 등록 말소와 법무장관 회부가 이어집니다. 공인회계사 자격이 있는 감사인은 요건을 충족한 것으로 간주되고, 회계위원회가 집행을 조율합니다.
이 숫자들을 한 그림에 놓으면 세 가지 시간 단위가 다르다는 것이 드러납니다.
신고 기한은 분기 단위, 독립성 점검은 연 단위, 보관은 십 년 단위입니다. 앞의 둘은 달력 알림으로 해결되지만, 세 번째는 아키텍처를 정해야 풀립니다.
10년 보관은 법무 문제가 아니라 저장소 문제입니다
보고서만 10년 두는 것은 쉽습니다. 어려운 것은 "관련 문서"입니다. 감사 결과가 왜 그렇게 나왔는지 다시 물으면 답할 수 있어야 하는데, 그러려면 실행 로그, 입력 샘플, 설정, 사용한 도구의 버전이 같이 남아 있어야 합니다. 요약본은 "관련 문서"의 범위를 구체적으로 적지 않았기 때문에, 얼마나 남겨야 하는지는 시행 규칙이 나와야 압니다.
감을 잡기 위해 설명용 시뮬레이션을 하나 돌려 봤습니다. 감사 1건의 증거 묶음을 4GB라고 가정하고, 연간 감사 건수를 10, 50, 200으로 놓았습니다. 4GB는 실측이 아니라 계산을 위한 가정입니다.
| 연간 감사 건수 | 건당 가정 용량 | 10년 누적 |
|---|---|---|
| 10건 | 4GB | 0.4TB |
| 50건 | 4GB | 2.0TB |
| 200건 | 4GB | 8.0TB |
용량만 보면 대수롭지 않습니다. 현실의 부담은 용량이 아니라 10년 뒤에도 읽히는가입니다. 파일 형식, 의존 도구의 버전, 암호화 키의 수명이 보관 기간을 따라가야 합니다. 이 글에서 제가 가장 강조하고 싶은 지점입니다. "보관한다"와 "그 시점에 열어서 같은 결과를 재현할 수 있다"는 다른 요구입니다.
증거 기록을 변조 감지 가능하게 남기는 법
보관과 별개로, 감사 기록이 사후에 바뀌지 않았다는 것을 보여 줄 수 있어야 합니다. 가장 단순한 방법은 기록마다 앞 기록의 해시를 물려 넣는 해시 체인입니다. 아래 스크립트는 표준 라이브러리만 쓰고, 보관 만료일 계산(윤년 2월 29일 처리 포함)도 함께 다룹니다.
import hashlib, json
from datetime import date
def retain_until(report_date: date, years: int = 10) -> date:
try:
return report_date.replace(year=report_date.year + years)
except ValueError: # 2월 29일
return report_date.replace(year=report_date.year + years, day=28)
def append(log: list, record: dict) -> dict:
prev = log[-1]["hash"] if log else "0" * 64
body = json.dumps(record, sort_keys=True, ensure_ascii=False)
h = hashlib.sha256((prev + body).encode("utf-8")).hexdigest()
entry = {"record": record, "prev": prev, "hash": h}
log.append(entry)
return entry
def verify(log: list) -> int:
"""깨진 첫 위치(0부터)를 돌려준다. 정상이면 -1."""
prev = "0" * 64
for i, e in enumerate(log):
body = json.dumps(e["record"], sort_keys=True, ensure_ascii=False)
if e["prev"] != prev or hashlib.sha256((prev + body).encode("utf-8")).hexdigest() != e["hash"]:
return i
prev = e["hash"]
return -1
log = []
append(log, {"audit": "A-001", "step": "scope", "note": "범위 확정", "date": "2029-03-02"})
append(log, {"audit": "A-001", "step": "result", "note": "통제 3건 미흡", "date": "2029-04-20"})
append(log, {"audit": "A-001", "step": "report", "note": "서명본 발행", "date": "2029-05-03",
"retain_until": retain_until(date(2029, 5, 3)).isoformat()})
print("정상:", verify(log)) # -1
log[1]["record"]["note"] = "통제 0건 미흡"
print("변조 후:", verify(log)) # 1
print(retain_until(date(2028, 2, 29))) # 2038-02-28
실제로 돌리면 정상일 때 -1, 두 번째 기록을 바꾼 뒤에는 1이 나옵니다. 변조된 기록 이후의 모든 해시가 함께 깨지므로, 어디서부터 믿을 수 없는지 위치가 드러납니다.
한계도 분명합니다. 해시 체인은 기록이 중간에 바뀌었다는 것을 알려 줄 뿐, 처음부터 거짓으로 적은 기록을 걸러 주지는 못합니다. 기록 전체를 통째로 새로 쓰는 공격을 막으려면 체인의 마지막 해시를 외부(감사 대상이 아닌 제3의 저장소나 타임스탬프 서비스)에 정기적으로 고정해 두어야 합니다. 이 예시는 설명용이며, 실제 등록 요건을 충족한다는 의미가 아닙니다.
킬스위치 이야기는 왜 같이 나오나요?
행정명령 N-9-26은 두 법의 이행을 앞당기면서, 현장 상주 IVO, 정부 검증 킬스위치, 통제 상실 사고를 포함한 확대된 안전 사고 보고를 검토하라고 지시했습니다. 11월 16일 권고안 제출이 바로 이 항목입니다. 지금까지 나온 요약만으로는 킬스위치가 어떤 형태의 의무가 될지 알 수 없고, 현재 법에는 요구 조항이 없습니다. 권고안이 나오면 달라질 수 있는 부분입니다.
이해관계를 밝힙니다. 비드래프트는 AI 모델 안에 운영체제와 킬스위치를 넣은 ViKernel을 공개했고, 이 주제에 이해관계가 있습니다. ViKernel이 이 법이나 앞으로의 권고를 충족한다고 말하는 것이 아닙니다. 이 글은 법의 구조를 설명하기 위한 글이고, 어떤 제품도 이 제도의 인증이나 등록을 받은 바가 없습니다. 킬스위치 구조에 관심이 있다면 아래 이전 글을 보세요.
아직 모르는 것
정직하게 적어 둡니다. 이 주제를 읽는 데 쓴 요약본들 사이에도 다른 부분이 있습니다.
- 적용 범위. 제가 대조한 요약은 "AI 감사를 제공하는 사람과 기관이 등록한다"고 쓰지만, 일부 글은 고영향 결정에 AI를 쓰는 모든 기업이 등록한다고 써서 서로 모순됩니다. 앞의 해석이 법률사무소 요약과 맞는다고 보지만, 본문 확인 전에는 단정하지 않습니다.
- 등록부 시작 시점. 어떤 요약은 2027년 12월 1일(등록부 설립과 등록 시작), 어떤 글은 2029년 1월 1일을 등록부 가동일로 적습니다. 저는 두 날짜를 "설립"과 "의무 시행"으로 나눠 읽는 쪽이 맞다고 보지만, 이것도 본문과 주 정부 공고로 확인해야 합니다.
- 벌칙. 등록 말소와 법무장관 회부까지만 확인했고 금액이나 소급 구제 여부는 확인하지 못했습니다.
- 한국 기업에 미치는 영향. 캘리포니아 안에서 감사 서비스를 제공하느냐에 달린 문제로 보이며, 국내 제도와의 대응은 별도 검토가 필요합니다. 저는 법률 전문가가 아닙니다.
- "관련 문서"의 범위. 10년 보관 대상이 어디까지인지는 시행 규칙이 나와야 압니다.
자주 묻는 질문
Q. 우리 회사가 AI를 쓰면 등록해야 하나요?
제가 확인한 요약 기준으로 등록 대상은 "covered AI audit"를 제공하거나 수행하는 사람과 기관입니다. AI를 쓰는 회사 자체가 아니라 감사를 하는 쪽입니다. 다만 앞에서 적은 대로 출처마다 표현이 달라 확정은 아닙니다.
Q. AI 감사를 받는 것이 의무가 되었나요?
아닙니다. 요약에 따르면 감사를 받는 것은 의무가 아니라 자발적이고, 받았다면 소송에서 책임 판단의 "관련은 있되 결정적이지 않은" 요소가 될 수 있습니다.
Q. 언제부터 단속하나요?
2029년 1월 1일부터 미등록 감사 제공이 금지됩니다. 등록부 설립과 등록 시작은 그보다 앞선 2027년 12월 1일로 요약되어 있습니다.
Q. 킬스위치가 의무가 되나요?
현재 법에는 없습니다. 행정명령이 정부 검증 킬스위치를 포함한 검토를 지시했고, 11월 16일에 권고안이 제출됩니다. 그 이후의 입법이나 규칙은 아직 알려진 바가 없습니다.
Q. 엔지니어는 지금 무엇을 해 두면 좋은가요?
법이 요구하는 형식을 아직 모르므로 확정적인 답은 없습니다. 다만 감사 증거를 재현 가능한 형태(입력, 설정, 도구 버전)로 남기고, 변조 감지가 되게 하고, 보관 형식이 10년 뒤에도 읽히는지 점검하는 것은 어떤 시행 규칙이 나와도 손해가 아닙니다.
정리
캘리포니아의 방향은 분명합니다. AI에 대한 외부 점검을 자격과 등록이 있는 직업으로 만들겠다는 것입니다. 그러나 날짜는 멀고(2029년), 세부 규칙은 아직 나오지 않았으며, 요약본마다 다른 부분이 있습니다. 지금 확인된 것은 숫자 몇 개(90일, 12개월, 10년, 2029-01-01)와 구조(등록 의무는 감사인에게, 감사는 자발적)입니다. 11월 16일 권고안이 나오면 킬스위치와 현장 상주 검증이 어떤 모양이 될지 첫 윤곽이 보입니다. 그때 이 글의 "아직 모르는 것"을 다시 확인해 고치겠습니다.
출처
- Crowell, California Establishes First-in-the-Nation Framework for Verifying Independent AI Auditors
- MNK Lawyers, California AI Audit Laws: SB 813 and AB 1405 Explained
Further reading
來源:DEV Community · dev.to