개요
System Card는 단일 머신러닝 모델의 특성만 기록하는 문서보다 넓은 범위에서, 실제 AI 시스템을 구성하는 여러 모델과 데이터 흐름, 비모델 구성요소, 상호작용과 사용 맥락을 설명하기 위한 문서화 방식이다. Meta의 System Cards 연구는 개별 모델 문서를 넘어 시스템 수준의 투명성을 제공하는 접근을 제안했다.[1]
Model Card와의 차이
Model Card가 특정 모델의 용도, 평가와 제한을 중심으로 기록한다면 System Card는 여러 구성요소가 실제 제품 안에서 어떻게 연결되는지까지 다룰 수 있다. 같은 모델을 사용하더라도 검색, 정책 필터, 외부 도구, 사용자 인터페이스와 데이터 처리 방식이 달라지면 최종 시스템의 행동과 위험도 달라질 수 있기 때문이다.[1]
운영 문서로서의 역할
System Card에는 Safety Evaluation과 Red Teaming의 범위와 결과, 알려진 제한사항, Data Provenance과 관련된 데이터 흐름, 배포 시 적용한 완화책 등을 연결할 수 있다. 문서를 작성했다는 사실 자체가 안전성을 보장하지는 않으며, 시스템 변경에 맞춰 실제 상태와 평가 결과를 지속적으로 갱신하는 것이 중요하다.
사례: 모델·검색·도구·필터의 연결 범위
가상의 AI 문서 도우미를 기반 모델, 문서 검색, 출력 필터, 초안 저장 도구로 구성한다고 하자. 시스템 카드에는 입력이 어느 구성요소를 지나고, 어떤 자료가 모델에 전달되며, 누가 저장을 요청할 수 있는지 적는다. 저장은 초안 생성 권한에 한정하고 공개 발행은 다른 조건이라는 예시 경계도 명시한다. 이는 실제 ORBiS Tree의 구현이나 특정 제품 설정을 설명한 것이 아니다.
모델 카드에 적힌 모델의 특성과 자료 경로, 도구 권한을 연결한다. Meta의 시스템 투명성 연구 ↗는 여러 구성요소의 상호작용과 정보 사용을 개괄하는 System Cards를 제안했다.[1] 구성요소를 나열하는 데서 그치지 않고 전달·저장·접근 경계를 적어야 실제 동작을 해석할 수 있다.
계산 예제: 모델 90%와 전체 시스템 60%
다음은 동일한 가상 10개 질문의 다른 평가 조건이다. 올바른 근거만 모델에 직접 제공한 시험에서는 9개 정답으로 90%였다. 검색을 포함한 전체 경로에서는 정답 근거를 찾은 질문이 8개이고, 그중 최종 답이 맞은 것이 6개였다. 이때 근거 검색 성공은 8 / 10 = 80%, 근거를 찾은 경우의 답변 성공은 6 / 8 = 75%, 전체 성공은 6 / 10 = 60%다.
자료 제공 조건이 다르므로 모델 점수와 서비스 점수를 같은 실험이라고 읽지 않는다. 검색 누락과 찾은 근거의 오독을 구분하고, 도구 저장이나 권한 판단의 성공 여부는 별도로 기록한다. 작은 가상 표본의 수치는 제품의 실제 성공률이나 일반적인 성능 기준이 아니다.
변경 시 다시 평가할 구성 묶음
설명용 버전 묶음이 모델 m1, 인덱스 i3, 지시 p5, 필터 f2, 도구 t4라고 하자. 모델 m1이 같아도 i3를 i4로 바꾸면 자료와 검색·답변 평가를 다시 연결해야 한다. 도구나 권한을 바꾸면 실제 행동의 허용·거부와 중복 쓰기·시간 초과 처리를 확인한다. 각 ID는 가상 식별자이며 특정 서비스의 설정명이 아니다.
변경 전 묶음과 복구 지점, 변경 사유, 평가 날짜·자료·기대 결과·관찰 결과, 남은 실패와 담당 조치를 남긴다. 예전 레드팀 결과를 새 도구 구성의 안전성 증거로 그대로 옮기지 않는다. 보고서 버전과 실제 배포 구성의 연결이 없으면 어느 시스템을 시험했는지 알기 어렵다.
감사 기록과 공개 범위를 함께 정하기
내부 알고리즘 감사 연구 ↗는 개발부터 배포까지의 판단과 단계별 기록을 연결하는 프레임워크를 제안했다.[2] 시스템 카드에는 평가 범위, 제외한 언어·상황, 완화책과 잔여 제한을 연결하고 공개 문서와 접근 제한된 재현 기록의 범위를 구분한다. 필요 없는 개인정보나 운영 비밀을 공개 보고서에 복사하지 않는다.
문서가 있다는 사실을 인증이나 모든 위험의 제거로 표현하지 않는다. 실제 구성에 맞는 재현 가능한 결과와 갱신 시점이 있어야, 이용자가 확인된 동작과 아직 시험하지 않은 영역을 구분할 수 있다.