AI가 문서를 편집하면, 변경에 대한 소유권은 누구에게 있나요?

문서는 누가 문장을 변경했는지는 보여줄 수 있지만, 현재 문구를 누가 승인했는지는 추측하게 합니다. AI와 사람이 모두 문구를 수정한 경우, 최종 편집 옆에 표시된 이름만으로는 그 질문에 답할 수 없습니다.

예를 들어, 2 영업일 이내에 응답을 약속하는 가상의 지원 정책을 생각해 보십시오. AI가 재작성한 제안은 1 영업일을 제시합니다. 인간 편집자는 이를 3 영업일로 변경하고, 팀 리더가 문서를 승인합니다. 배포된 파일은 평범해 보입니다. 그 기록에는 거부된 제안, 인간의 수정, 그리고 고객이 기대해야 할 사항에 대한 결정이 포함됩니다.

그 변경에 대한 소유자는 누구인가요? 우리는 기여를 구분한 뒤에야 이를 배포할 책임을 할당할 수 있습니다. 그렇지 않으면 “AI 지원”이라는 말만으로는 최종 문구가 어떻게 도출되었는지 거의 알 수 없습니다.

편집과 결정 분리하기

Microsoft의 2025년 9월 29일 발표에 따르면 Agent Mode in Word이 Frontier 롤아웃을 시작했습니다는 대화형 편집을 문서 애플리케이션에, 처음에는 웹에서 제공했습니다. 해당 발표는 롤아웃 날짜를 명시할 뿐, 특정 조직이 결과 변화를 어떻게 검토하는지는 다루지 않습니다.

AI를 이렇게 활용하는 팀에게 유용한 시작점은 편집을 요청한 사람입니다. 해당 사람을 제안을 생성한 소프트웨어와 별도로 기록하십시오. 누군가가 제안을 다시 작성하면 그 기여도 보존해야 합니다. 승인은 또 다른 행동으로, 검토자가 실제로 본 버전에 연결됩니다.

이러한 역할은 모든 작업마다 별도의 인력이 필요하지 않습니다. 편집자는 재작성 요청, 수정, 그리고 승인 권한을 가질 수 있습니다. 구분은 여전히 중요합니다: 짧은 단락을 요청한다고 해서 소프트웨어가 만든 모든 변경을 승인한다는 의미는 아닙니다.

The W3C PROV data model은 이 기록을 설명하기 위한 어휘를 제공합니다. 문서와 그 버전은 엔터티로, 편집 및 승인은 활동으로, 사람과 소프트웨어는 에이전트로 표현될 수 있습니다. 이 모델은 이들 간의 관계를 설명합니다. 그러나 법적 책임을 결정하거나 저자 필드에 표시된 사람을 인증하지는 않습니다.

기술 문서 작성이나 지원 자료와 관련된 AI 지원 문서 워크플로에서는 각 기록된 행동이 무엇을 의미하는지 정의해야 합니다. 댓글은 논의에 대한 기여를 식별합니다. 승인은 특정 문구를 공개할 권한을 식별해야 합니다. 두 가지에 동일한 일반적인 “검토됨” 상태를 부여하면 기록의 유용성이 떨어집니다.

변경된 한 구절에 대한 기록 만들기

응답 시간 예제로 돌아갑니다. 재작성 생성 전에 승인된 2 영업일 문구와 해당 문서 버전을 보존하십시오. 제안된 변경에 식별자를 부여하고, 이후 수정 및 결정을 그에 연결합니다.

다음은 가상의 식별자를 사용한 예시 설계입니다. 이는 테스트된 제품의 출력이거나 모든 문서 도구가 지원하는 스키마가 아닙니다.

인간 수정이 AI 제안을 대체한 후에도 AI 제안을 보존하십시오. 기록에 최종 3 영업일 문구만 남겨진다면, 이후 검토자는 해당 항목에서 이전 제안을 재구성할 수 없습니다. 거부된 변경도 기록의 일부이며, 비록 게시된 텍스트에 포함되지 않더라도 마찬가지입니다.

NIST의 2024년 7월 Generative AI Profile은 출처 정보를 콘텐츠의 원본 및 이력, 수정 및 출처를 포함한 정보로 정의합니다. 또한 출처 프로세스와 인간 검토자 간의 관계를 평가할 것을 권고합니다. 이 표는 해당 아이디어를 문서 워크플로에 적용한 것이며, NIST 인증 체크리스트가 아닙니다.

이 기록은 문서 시스템 내에 보관하거나 연결된 저장소에 보관할 수 있습니다. 어느 쪽이든, 배포된 버전과의 관계를 충분히 명확히 하여 원 편집자의 기억에 의존하지 않고도 누군가가 이를 검색할 수 있도록 하십시오.

인수인계 시 남는 내용 확인하기

내보낸 파일은 별도의 검증이 필요합니다. 편집 중에 이용 가능한 기록은 수신자가 확인할 수 있는 내용과 다를 수 있으며, 이는 애플리케이션, 형식 및 내보내기 설정에 따라 달라집니다. 모든 PDF가 저작권 표시를 잃는다고 가정하거나, 보이는 주석을 보존한다고 해서 모든 검토 결정이 보존된다고 생각하지 마세요.

Microsoft의 현재 Copilot을 사용한 편집에 대한 문서는 해당 기능이 활성화된 경우 변경 사항이 추적 변경을 존중한다고 명시합니다. 이는 유용한 기능입니다. 그러나 전체 승인 기록이 이후 모든 변환이나 인계 과정에서 유지된다고 보장하지는 않습니다.

팀이 실제로 사용하는 흐름을 테스트하세요. 예시 문서를 검토와 내보내기 과정을 거치게 한 뒤, 보존된 기록을 이용해 승인된 개정판과 승인자를 복구해 보세요. 배포된 파일이 해당 기록을 담을 수 없을 경우, 별도의 관리 기록을 유지하고 양자 간 연결을 보존하십시오.

덜 명확한 경우도 주의를 기울여야 합니다. 제안 중 일부만 수용하고 기록이 무엇을 말하는지 확인하세요. 두 명의 검토자가 동일한 기본 버전에서 작업하도록 한 뒤, 어떤 변경 사항이 배포 파일에 반영되었는지 확인합니다. 마지막으로, 승인 후 해당 구절을 편집하고 이전 결정이 새로운 문구에 대한 승인이 되지는 않았는지 검증하십시오.

표시된 저자 이름은 신원 확인을 위해 해당 이름이 인증된 계정과 연결될 수 있어야 합니다. 마찬가지로 파일 다이제스트는 배포된 아티팩트를 식별하는 데 도움이 되지만, 응답 시간 약속이 정확한지 여부는 알려주지 못합니다. 이는 별개의 검증이며, 검토 프로세스에서 이 구분을 유지해야 합니다.

배포 전 승인 경계 설정

제목 서식 변경과 고객 약속 변경은 동일한 검토 절차를 따를 필요가 없습니다. 기존 정책에 따라 진행 가능한 편집과 지정된 담당자의 승인이 필요한 편집을 구분하세요. 이러한 선택은 변경 사항이 문서를 사용하는 사람들에게 어떤 의미인지를 반영해야 합니다.

여기서는 명시적 AI 의사결정 권한에 대한 주장이 실용적으로 적용됩니다. 예시에서는 누군가가 3영업일 응답 약속을 승인할 권한이 필요합니다. 파일 편집 권한만으로는 해당 권한의 증거로 간주해서는 안 됩니다.

검토자에게 충분한 맥락을 제공하여 판단할 수 있게 하세요. 원본 문구와 제안된 문구를 중간에 발생한 인간 수정과 함께 표시합니다. 해결되지 않은 충돌을 가시화하고, 배포 대상 버전을 명확히 식별하십시오. 최종 다듬어진 단락만 보는 검토자는 응답 시간이 변경되었는지 알 이유가 없을 수 있습니다.

워크플로를 사용자에게 넘기기 전에 배포 책임자를 확정하십시오. 해당 인물이 모든 편집을 수행할 필요는 없지만, 필요한 검토가 이루어졌으며 배포 파일에 적용되었음을 입증할 방법이 필요합니다. 담당자를 모호하게 두면 문서가 최종 단계에 이르렀을 때 분쟁이 발생한 변경 사항을 해결하기 어려워집니다.

이는 모든 기밀 프롬프트를 무기한 보관해야 한다는 의미는 아닙니다. 조직의 접근 및 보존 정책에 따라 결정을 설명하는 데 필요한 증거를 유지하십시오. 모델 버전 정보가 없을 경우 그 제한을 기록합니다. 유용한 기록은 누락된 정보를 명확히 드러내야 하며, 시스템이 포착하지 못한 세부 수준을 암시해서는 안 됩니다.

확인 가능한 버전만 배포

중대한 변경을 배포하기 전에 기록을 통해 해당 변경을 추적해 보세요. 원본 제안을 찾고, 인간 편집자가 어떤 부분을 수정했는지 확인한 뒤, 해당 개정을 승인한 결정을 찾아냅니다. 그런 다음 승인된 버전과 실제 전달되는 파일을 비교하십시오.

그 연결이 없을 경우, 검토 변경을 보류하십시오. 누군가 문서가 ‘승인’되었다고 기억하는 것만으로는 어떤 문구가 승인되었는지 입증하기에 충분하지 않습니다.

편집자는 AI가 만든 모든 제안을 할당받지 않더라도 자신의 기여를 설명할 수 있어야 합니다. 배포 담당자는 자신이 승인하는 내용이 정확히 무엇인지 알아야 합니다. 우리는 사람들에게 변경 사항에 책임을 묻되, 그 변경이 어떻게 이루어졌는지 검증할 신뢰할 수 있는 방법을 제공하지는 못합니다.