AI 외부 평가: 접근 권한과 비용의 출처
외부 평가자가 AI 회사 안에 들어가 직원처럼 자료를 볼 수 있다면 무엇이 달라질까. 공개된 모델을 시험하는 것보다 개발 과정을 가까이 볼 수 있다. 동시에 누가 평가 비용을 내고, 불리한 결과도 공개할 수 있는지라는 질문이 생긴다.
9월 18일 Anthropic은 Accenture와 내부 상주 평가를 추진한다고 발표했다. 직원에 준하는 접근을 제공하고 평가 비용은 Anthropic이 직접 부담할 계획이다. 접근·보고·재원에 관한 공통 기준은 아직 정해지지 않았다고 밝혔다. Anthropic 발표
Accenture의 발표는 Faculty의 전문성을 바탕으로 모델과 보호 장치를 시험할 팀을 구성한다고 설명한다. 공격 상황에서의 동작과 사용자·개발자의 의도에 맞게 행동하는지도 평가 대상이다. 이는 협력 계획이며, 완료된 감사 결과가 아니다. Accenture 발표
접근할 수 있어야 평가할 수 있는 것
같은 모델 이름이라도 실제 작업에 붙는 도구와 권한은 다를 수 있다. 그래서 내가 이 계획에서 먼저 확인하고 싶은 것은 ‘얼마나 어려운 문제를 풀게 하는가’보다 평가자가 정확히 어떤 실행 조건을 보는가다.
예를 들어 파일을 읽는 AI를 시험한다고 가정하자. 모델에 “허용된 폴더만 읽어라”라고 지시한 뒤 답변을 보는 검사는 지시 준수에 관한 근거를 준다. 실제 파일 접근을 환경에서 막았는지 확인하려면 다른 근거가 필요하다. 프로세스 권한, 사용 가능한 도구, 거부된 요청의 로그까지 봐야 한다.
이 예시에서 내부 접근의 가치는 실패의 원인을 나눌 수 있다는 데 있다. 모델이 읽으려 하지 않은 것인지, 시도했지만 환경이 막은 것인지, 아예 해당 도구가 없었던 것인지가 다르다. 최종 답변만 보면 셋 다 ‘문제없음’처럼 보일 수 있다.
다만 직원에 준하는 접근이라는 표현만으로 모든 로그, 모델 가중치, 훈련 중간 상태를 제한 없이 열람한다고 단정할 수는 없다. 실제 계약과 운영 범위가 공개돼야 확인할 수 있는 내용이다.
독립성을 나누어 볼 세 가지 권한
독립 평가라는 이름을 한 번에 통과·실패로 판정하기보다 세 질문으로 나누어 읽겠다.
| 구분 | 확인할 질문 | 부족할 때 생기는 문제 |
|---|---|---|
| 자료 접근 | 실패 사례와 실제 배포 설정까지 선택해 볼 수 있는가? | 회사가 고른 성공 사례만 평가할 수 있다 |
| 평가 판단 | 시험 방법·중단 기준·결론을 누가 결정하는가? | 결과에 맞춰 기준을 바꿀 수 있다 |
| 결과 공개 | 회사와 의견이 달라도 보고할 수 있는가? | 내부에서 발견한 문제가 밖에는 알려지지 않을 수 있다 |
위 표는 이번 발표를 검토하기 위해 만든 질문이다. 실제 협력에서 이런 문제가 발생했다고 주장하는 목록이 아니다.
비용의 출처도 이 세 권한과 연결해서 봐야 한다. 평가 대상 회사가 돈을 낸다는 사실은 이해관계를 살펴볼 이유가 된다. 그것만으로 평가가 조작됐다는 증거가 되지는 않는다. 반대로 외부 기관이라는 명칭만으로 결론과 공개가 독립적이라고 보장할 수도 없다.
공개되지 않은 조건은 ‘없다’가 아니라 ‘확인하지 못했다’로 남기는 편이 정확하다. 특히 해고·계약 종료 조건, 보고 지연 가능 기간, 이견을 전달하는 경로는 발표 문구만으로 채워 넣지 않겠다.
평가한 모델과 배포한 시스템의 연결
기술적으로 더 어려운 질문은 평가 결과가 어느 시스템에 적용되는가다. 모델 버전이 같더라도 외부 전송 도구를 추가하거나 네트워크 권한을 넓히면, 이전 검사가 보지 못한 행동 경로가 생길 수 있다.
가상의 문서 분석 서비스를 놓고 생각해 보자.
평가 당시: 문서 읽기 → 로컬 요약 저장
배포 변경: 문서 읽기 → 로컬 요약 저장 → 외부 공유 링크 생성새 경로에는 전송 대상, 전송할 파일, 공유 범위라는 확인 항목이 추가된다. 이전 평가가 요약 정확성을 확인했다는 사실만으로 새 공유 기능까지 검증됐다고 말할 수 없다.
따라서 평가 보고서가 남겨야 할 최소 연결 정보를 이렇게 제안한다.
| 기록 | 남길 내용 |
|---|---|
| 대상 | 모델과 실행 프로그램의 버전 |
| 환경 | 도구 목록, 계정 권한, 네트워크 접근 범위 |
| 입력 | 시험 자료와 해당 자료를 고른 조건 |
| 결과 | 성공 사례뿐 아니라 실패·중단·미완료 기록 |
| 변경 | 평가 뒤 달라진 설정과 다시 확인할 검사 |
이 기록이 있으면 ‘이 AI는 평가를 통과했다’는 넓은 문장을 더 정확하게 바꿀 수 있다. 어떤 설정에서 어떤 시험을 통과했고, 어느 변경부터 재검사가 필요한지 말할 수 있기 때문이다. 상주 평가가 효과적인지 판단할 때도 이런 연결 기록이 실제로 남는지 보겠다.
작은 AI 프로젝트에 적용할 부분
개인 프로젝트에서 외부 평가 조직을 그대로 만들 필요는 없다. 대신 구현과 검토가 같은 자료를 보더라도 같은 결론을 전제로 시작하지 않도록 작업을 설계할 수 있다.
예를 들어 작성자는 구현 파일과 자신이 통과한 검사만 넘기는 데 그치지 않고, 원래 요구와 실패했던 입력도 전달한다. 검토자는 그 요구에서 확인 항목을 정하고 실제 결과를 비교한다. 발견한 문제는 수정 뒤 다시 실행한 결과와 연결해 남긴다.
이 방식은 비용을 낸 조직의 독립성을 해결하는 제도적 대안은 아니다. 이 글에서 제안하는 작은 적용 범위는 검토자가 결론을 바꿀 수 있는 근거를 직접 볼 수 있게 하는 것이다. 이번 발표에서 아직 확인되지 않은 권한을 우리 작업에서도 말로만 있다고 가정하지 않는 데 의미가 있다.
앞으로 이 협력의 성과를 판단할 자료는 계약 발표의 규모보다 구체적인 평가 기록이다. 실제로 볼 수 있었던 자료, 발견한 실패, 회사와 의견이 갈렸을 때의 처리, 평가 뒤 바뀐 실행 조건을 확인해야 한다.
자료 확인: 2026년 9월 21일. 양사 공개 발표를 분석했다. 비공개 계약이나 실제 평가 결과를 확보한 것은 아니며, 표와 서비스 예시는 이 글의 검토안이다.