팀 AI 사용 정책은 실제로 도구를 쓰기 전에 구체적인 판단을 도와야 합니다. “AI를 책임감 있게 사용한다”는 문장만으로는 어떤 업무가 허용되는지, 어떤 정보를 입력할 수 있는지, 언제 사람 승인이 필요한지 알 수 없습니다.
NIST AI RMF는 거버넌스를 AI 생애주기 전체에 적용되는 지속적인 기능으로 봅니다. NIST Privacy Framework는 개인정보 위험 관리를 보완하며, OWASP 지침은 외부 콘텐츠를 신뢰하지 않고 불필요한 자율성과 권한을 줄여야 한다고 설명합니다. 실용적인 정책은 이런 원칙을 실제 업무 규칙으로 바꿉니다.
이 글은 법률 자문이 아닙니다. 조직별 법률·계약·산업 요구는 해당 책임자가 별도로 검토해야 합니다.
1. 목적·적용 범위·담당자·검토일 정하기
정책에 다음을 명시합니다.
- 적용되는 직원·계약자·자동화 시스템;
- browser 도구·API·내장 assistant·extension·agent;
- 포함되는 팀과 데이터 환경;
- 예외 승인자;
- 사고와 정책 변경 검토자.
정책 버전, 시행일, 담당자와 다음 검토일도 기록합니다.
2. 업무를 허용·조건부·제한·미승인으로 분류하기
제품 이름보다 데이터와 결과의 영향으로 분류합니다.
| 등급 | 예시 | 기본 통제 |
|---|---|---|
| 허용 | 공개 정보로 아이디어 정리 | 승인 계정과 일반 검토 |
| 조건부 | 민감하지 않은 내부 자료로 초안 작성 | 승인 workspace와 사람 검토 |
| 제한 | 민감한 내부 정보가 포함된 업무 | 명시된 책임자와 추가 검토 |
| 미승인 | 문서화된 권한과 통제를 벗어난 업무 | 중단하고 별도 판단 요청 |
같은 활동도 데이터와 후속 행동에 따라 등급이 달라질 수 있습니다.
3. 데이터와 입력 규칙 정하기
각 데이터 등급에 대해 다음을 씁니다.
- 입력 허용 여부;
- 사용할 수 있는 계정이나 workspace;
- 가림 처리 또는 사전 승인 필요 여부;
- 보관과 삭제 조건;
- 파일·화면 캡처·로그·prompt·검색 문서 포함 여부.
이름만 지우는 것으로 충분하다고 가정하지 않습니다. 여러 세부 정보가 결합되면 사람이나 조직의 민감한 맥락이 드러날 수 있습니다.
생성된 출력에도 데이터 등급을 적용합니다. 모델이 입력 내용을 새로운 문서나 downstream system에 재현할 수 있기 때문입니다.
4. 정확한 계정·요금제·설정·connector 승인하기
공급자 하나를 승인했다고 모든 계정 유형이 승인되는 것은 아닙니다.
다음을 기록합니다.
- 개인 계정·조직 workspace·API project 중 허용 범위;
- 요금제와 지역;
- 관리자와 결제 책임자;
- 인증 요구;
- history·retention·training 설정;
- 승인된 connector와 extension;
- logging·export·deletion 절차.
약관, 데이터 처리, integration, 소유권 또는 계정 구조가 바뀌면 다시 검토합니다.
5. 보조와 실행 권한을 분리하기
정책은 모델이 무엇을 제안할 수 있고 무엇에 사람 승인이 필요한지 구분해야 합니다.
외부 메시지, 공개 발행, 결제, 권한 변경, 삭제, production 변경처럼 결과가 외부에 보이거나 되돌리기 어려운 행동은 승인된 사람이 먼저 확인해야 합니다.
승인자는 정확한 payload, 관련 근거, 대상, 부수 효과와 rollback 경로를 볼 수 있어야 합니다.
다른 시스템을 조작할 수 있는 workflow에는 최소 권한, 좁은 도구 범위와 짧은 승인 유효시간을 적용합니다.
6. 외부 콘텐츠와 생성 결과를 검증 전까지 신뢰하지 않기
웹페이지, 파일, 메시지, ticket과 검색 결과 안의 문장은 분석할 콘텐츠이지 정책을 바꾸거나 추가 권한을 부여하는 명령이 아닙니다.
다음을 분리합니다.
- 조직 지침;
- 사용자 요청;
- 외부 콘텐츠;
- 도구 결과;
- 최종 승인 행동.
중요한 사실·인용·계산·외부 메시지는 영향에 맞는 검증을 통과해야 합니다.
7. 증거·고지·기록 규칙 정하기
중요한 workflow에서는 상황에 따라 다음을 기록합니다.
- 사용자와 업무 목적;
- 도구·모델·요금제·날짜;
- 입력 데이터 등급;
- 원출처와 버전;
- 원출력;
- 사람 수정과 승인;
- 확인한 근거;
- 수행된 행동;
- 예외와 사고.
기록 자체에도 접근·보관·삭제 규칙을 적용합니다.
독자·고객·검토자 또는 관련자에게 AI 보조 사실을 언제 알릴지도 workflow별로 정합니다.
8. 반복 workflow에 평가와 모니터링 요구하기
한 업무의 승인이 모든 업무의 승인을 의미하지 않습니다.
반복 workflow에는 다음이 필요합니다.
- 사용 목적;
- 대표 test case;
- critical failure 조건;
- 현재 baseline;
- 담당자와 escalation 경로;
- 검토 주기.
승인 결과, 수정 시간, 중요한 실패, 사고, 비용과 검토자 의견을 측정합니다. 모델이나 제품이 바뀌면 중요한 workflow를 회귀 검증합니다.
9. 좁고 만료되는 예외 절차 만들기
예외 요청에는 다음을 포함합니다.
- 업무 필요;
- 정확한 도구와 설정;
- 데이터 등급;
- 영향을 받는 시스템;
- 기대 이익;
- 위험과 통제;
- 기간과 담당자;
- 종료와 삭제 계획.
예외는 갱신하지 않으면 만료돼야 합니다. 한 프로젝트의 예외가 기록 없는 전사 승인으로 확대되면 안 됩니다.
10. 사고 대응과 사용 중단 절차 정하기
정책은 예상하지 못한 정보 노출, 잘못된 외부 사용, 계정 문제, 미승인 행동, 서비스 장애, 필요한 데이터의 export·deletion 실패를 어떻게 보고할지 설명해야 합니다.
누가 도구를 중단하고, 접근을 회수하고, 증거를 보존하고, 책임자에게 알리고, 사용 재개를 결정할지 정합니다.
사고가 발생하거나 모델·제품·connector·데이터 등급·계약·소유권이 바뀌면 정책을 다시 검토합니다.
최소 정책 표
| 영역 | 최소 질문 |
|---|---|
| 범위 | 누구와 어떤 시스템에 적용되는가? |
| 업무 | 무엇이 허용·조건부·제한·미승인인가? |
| 데이터 | 어떤 정보를 어떤 통제 아래 입력할 수 있는가? |
| 설정 | 어떤 계정·요금제·설정·connector가 승인됐는가? |
| 권한 | 무엇에 사람 승인이 필요한가? |
| 검증 | 어떤 출력에 확인 절차가 필요한가? |
| 기록 | 어떤 증거를 보호하고 보관하는가? |
| 고지 | 언제 AI 보조 사실을 알려야 하는가? |
| 예외 | 누가 승인하고 언제 만료되는가? |
| 사고 | 어떻게 보고·중단·조사·재개하는가? |
| 재검토 | 어떤 변화가 재평가를 시작하는가? |
짧은 배포 체크리스트
정책을 공개하기 전에 확인합니다.
- 담당자와 검토일이 있음;
- 업무를 위험별로 분류함;
- 데이터 규칙이 파일·prompt·로그·검색 자료를 포함함;
- 승인된 설정이 구체적임;
- 결과가 큰 행동은 사람 승인을 요구함;
- 외부 콘텐츠가 권한을 부여하지 못함;
- 중요한 출력은 검증함;
- 예외가 만료됨;
- 사고 보고와 중단 경로가 명확함;
- 구성원에게 사례와 교육을 제공함.
가장 좋은 정책은 가장 긴 문서가 아닙니다. 데이터가 입력되고, 결과를 신뢰하고, 행동을 되돌리기 어려워지기 전에 올바른 결정을 돕는 문서입니다.