이곳에 법적 공백은 존재하지 않습니다. 소프트웨어의 도움으로 발생한 피해는 이 기술보다 훨씬 오래전에 정립된 법리(doctrines)에 따라 수십 년 동안 소송이 진행되어 왔습니다. 흥미로운 질문은 이러한 법리들이 어떻게 적용되는지에 관한 것이지, 적용 가능한 법리가 있는지에 관한 것이 아닙니다. 이 페이지의 어떤 내용도 법적 조언이 아닙니다.

이미 존재하는 이론들

모델은 제품인가?

이것이 법리적 핵심(doctrinal hinge)이며, 왜 이것이 그토록 중요한지 이해할 가치가 있습니다. 엄격한 제조물 책임 (Strict product liability)은 누군가가 불합리하게 행동했다는 것을 증명해야 하는 요건을 제거합니다. 청구인은 제품에 결함이 있었고 그로 인해 피해가 발생했음을 보여주기만 하면 됩니다. 메커니즘이 불투명하고 피고의 내부 프로세스를 볼 수 없을 때, 과실(fault) 요소를 제거하는 것은 결정적인 역할을 합니다.

제조물 책임 체계는 제조된 상품을 위해 작성되었습니다. 소프트웨어가 제품인지 여부는 수십 년 동안 논쟁이 되어 왔으며, 물리적인 물체에 내장된 소프트웨어(보통 제품의 일부로 취급됨)와 단독으로 제공되는 소프트웨어(더 쉽게 서비스로 특징지어짐) 사이의 일반적인 구분이 존재합니다. API를 통해 접속하는 모델은 그 스펙트럼의 가장 끝에 위치하며, 이것이 여러 개혁 노력들이 소프트웨어와 디지털 서비스도 제품에 포함된다고 명시적으로 제안하는 이유입니다.

이러한 논쟁은 양방향으로 전개되며 양측 모두 심각한 근거를 가지고 있습니다. 포함론(inclusion) 측의 주장은 다음과 같습니다: 청구인은 행동이 결정론적(deterministic)이지 않고 개발 과정을 관찰할 수 없는 시스템에서 과실을 현실적으로 증명할 수 없으며, 무과실 책임(strict liability)의 정책적 근거인 '결함을 방지하고 이에 대비해 보험을 들기에 가장 적합한 위치에 있는 당사자가 책임을 져야 한다'는 원칙이 강력하게 적용된다는 것입니다. 반대론 측의 주장은 다음과 같습니다: 무과실 책임은 결함이 사양(specification)으로부터의 일탈인 대량 생산 제품에 대해 정당화되었으나, 범용 모델(general-purpose model)은 일탈할 사양 자체가 존재하지 않으며, 그 출력값은 개발자가 결코 볼 수 없는 입력값(inputs)에 의존하고, 이 교리는 예측 불가능한 사용에 대해 책임을 부과할 위험이 있다는 것입니다.

세 가지 결함 이론의 적용

제조 결함 (Manufacturing defect) — 제품이 자체 설계에서 벗어난 경우입니다. 이와 유사한 사례는 본질적으로 존재하지 않습니다. 가중치 파일(weight file)의 모든 복사본은 동일하기 때문입니다. 가장 유사한 것은 서빙 오류(serving fault), 잘못된 양자화(quantisation), 손상된 배포(corrupted deployment) 등이며, 이는 운영상의 일반적인 과실(negligence)로 분석하는 것이 더 적절합니다.

설계 결함 (Design defect) — 설계 자체가 비합리적으로 위험한 경우입니다. 대부분의 공식에서 이는 위험-효용 테스트(risk-utility test)로 다뤄지며, 흔히 청구인이 제품의 성능을 과도하게 저해하지 않으면서도 피해를 방지할 수 있는 합리적인 대안 설계를 식별할 것을 요구합니다. 모델에 이를 적용하면 평가(evaluations), 안전 학습(safety training), 가드레일(guardrails), 거부 행동(refusal behaviour) 및 공개된 완화 조치(mitigations)가 모두 증거가 됩니다. 즉, 무엇이 실행 가능했는지, 무엇이 알려져 있었는지, 그리고 무엇을 하지 않기로 선택했는지에 대한 증거가 됩니다. 이로 인한 실질적인 함의는 불편하며 언급할 가치가 있습니다. 안전 관련 문헌(safety literature)은 달성 가능한 최첨단 기술(state of the art)을 정의하는 동시에, 피고가 무엇을 누락했는지에 대해 비판받을 수 있는 기준을 정의하게 됩니다.

경고 의무 위반 (Failure to warn) — 위험이 알려져 있었음에도 불구하고 부적절하게 전달된 경우입니다. 이는 모델 카드 (model cards) 및 문서화 (documentation)가 다루고자 하는 이론입니다. 이 이론의 한계는 다른 산업 분야에서도 잘 확립되어 있습니다. 즉, 아무도 읽지 않는 약관 속에 숨겨진 경고는 효력이 약하며, 경고가 안전하게 설계될 수 있었던 설계를 정당화해주지도 않고, 과도한 경고는 경고의 효과를 희석시킵니다. 또한, 사용자가 경고에 따라 조치를 취할 수 없는 상황, 즉 여러 단계를 거쳐 하류 (downstream)에 위치한 최종 사용자 (end user)의 상황에서는 경고의 역할이 줄어듭니다.

인과관계 (Causation)가 진정한 격전지입니다

교리 (Doctrine)가 주목을 받지만, 인과관계 (causation)와 증거가 사건을 결정합니다. 원고는 출력이 피해를 일으켰음을 입증해야 하며, 이는 세 가지 실질적인 장애물에 부딪힙니다.

출력은 대개 재현 불가능합니다 (not reproducible). 샘플링은 확률적 (stochastic)이며, 모델 버전은 변경되었고, 시스템 프롬프트 (system prompt)도 바뀌었습니다. 로그 (log)가 없다면 실제로 무엇이 생성되었는지에 대한 허용 가능한 기록이 없을 수 있습니다. 관련 정보 — 학습 데이터 (training data), 평가 결과 (evaluation results), 내부 위험 평가 (internal risk assessments) — 는 피고가 보유하고 있습니다. 그리고 개입 행위 (intervening acts)가 인과 관계의 사슬을 끊습니다. 즉, 사람이 검토했거나, 배포자 (deployer)가 설정을 변경했거나, 사용자가 경고를 무시한 경우입니다.

이것이 제안된 책임 체계 (liability regimes)에서 가장 중대한 조항들이 실체적 (substantive)인 내용보다는 절차적 (procedural)인 내용이라는 이유입니다. 피고에게 문서 제출을 요구하는 공시 의무 (disclosure duty), 또는 원고가 안전 의무 미준수를 입증했을 때 인과관계의 반박 가능한 추정 (rebuttable presumption of causation)을 적용하는 것은, 해결 불가능한 불확실성을 누가 부담할 것인가를 변화시킵니다. 이 단일 메커니즘은 소프트웨어가 제품인지에 대한 그 어떤 논쟁보다 더 많은 위험을 재배분합니다.

체인 내에서 실제로 누가 책임을 지는가

개발자 (Developer), 미세 조정자 (fine-tuner), 통합자 (integrator), 배포자 (deployer), 전문 사용자 (professional user). 기본 패턴은 피해 당사자와 관계를 맺고 있는 쪽이 먼저 소송을 당한 뒤, 손실을 상류 (upstream)로 전가하려고 시도하는 것입니다. 따라서 실질적인 배분은 계약에 의해 결정됩니다: 면책 범위 (indemnity scope), 책임 제한 (liability caps), 출력물에 대한 보증 여부 — 일반적으로는 보증되지 않습니다 — 필터링 의무가 누구에게 있는지, 그리고 누구의 허용 가능한 사용 정책 (acceptable use policy)이 적용되는지 등이 그것입니다.

또한 상당한 수정 (substantial modification)이 이루어지면 보통 책임이 전환된다는 점에 유의하십시오. 모델을 미세 조정 (fine-tune)하거나 개발자가 제외한 목적으로 모델을 배포하는 당사자는 여러 규제 체제 하에서 해당 수정된 제품의 생산자 (producer) 지위를 맡게 되는 경향이 있습니다. 이는 자신이 고객이라고 생각했던 조직에게 가장 놀라움을 줄 가능성이 높은 조항입니다.

법리가 무엇으로 밝혀지든, 실제로 통제할 수 있는 배분은 계약에 의한 것이며, 이는 가정하기보다는 직접 읽어볼 가치가 있습니다. Multigrid의 약관은 모든 제공업체가 그러하듯 모델 출력에 대해 무엇이 보증되고 무엇이 보증되지 않는지를 명시하고 있습니다. 분쟁 시 중요한 조항은 보증 면책 (warranty disclaimer), 책임 제한 (liability cap), 그리고 면책 범위 (indemnity scope) 순서입니다.

관할권과 관계없이, 다음 네 가지 사항이 노출 (exposure)을 변화시킵니다: 실제로 무엇이 어떤 설정으로 생성되었는지를 보존하는 로깅 (logging); 피해가 돌이킬 수 없게 되는 지점에서의 인간의 결정 단계 (human decision point); 허용된 사용 범위를 설정하고 단순히 명시하는 것을 넘어 이를 강제하는 것; 그리고 실제 배포 상황에 맞춰 검토된 보험입니다. 이 페이지는 논쟁의 형태만을 설명합니다. 책임법 (liability law)은 관할권마다 실질적으로 다르며 변화하고 있습니다. 전문가의 조언을 구하십시오.

이것이 소송을 넘어 왜 중요한지에 대한 마지막 논점입니다. 책임 규칙 (Liability rules)은 가격 결정 메커니즘 (pricing mechanism)입니다. 즉, 누구의 예산이 피해를 흡수할 것인지, 따라서 누가 피해를 방지해야 할 경제적 이유를 갖게 될 것인지를 결정합니다. 손실을 줄일 능력이 가장 적은 당사자에게 책임을 지우는 규칙은 안전보다는 보험 (insurance)을 만들어내고, 시스템을 변경할 수 있는 가장 적절한 위치에 있는 당사자에게 책임을 지우는 규칙은 공학적 개선 (engineering)을 만들어냅니다. 이것이 교리적인 (doctrinal) 질문 아래에 깔린 실질적인 질문이며, 논쟁할 가치가 있는 지점입니다.

관련 항목

• 알고리즘 책임성과 설명 요구권 (Algorithmic Accountability and the Right to Explanation)
• 누가 AI를 통제하는가? 실제 기관의 지도 (Who Governs AI? A Map of the Actual Institutions)
• AI에 의한 콘텐츠 중재: 규모, 오류 및 이의 제기 (Content Moderation by AI: Scale, Errors and Appeals)