RFP를 받으면 AI부터 끄자: NATO 사례로 보는 제안서 AI 적격성 관리

조회 457좋아요 0

요즘 제안서 제작에 AI를 붙이는 일은 어렵지 않습니다. RFP를 요약하고, 요구사항을 표로 만들고, 목차를 잡고, 초안을 보완하는 데까지 생성형 AI를 활용할 수 있습니다. 제안 조직 입장에서는 속도와 생산성을 높이는 자연스러운 선택입니다.

하지만 이제는 RFP를 받자마자 AI에게 문서를 읽히는 습관부터 멈춰야 할 사업이 생겼습니다. 제안서를 잘 쓰기 전에, 이 사업에서 생성형 AI를 써도 되는지부터 확인해야 합니다. 규정을 뒤늦게 발견하면 이미 AI에 넣은 자료와 AI가 손댄 초안을 되돌리기 어렵기 때문입니다.

AI 사업의 제안서에서 AI 사용을 금지한 NATO 사례

NATO Allied Command Transformation의 RFP-ACT-SACT-26-54 Amendment 2는 Secure Cloud Service 구축 사업입니다. 사업 범위에는 외부 인터넷이나 외부 AI 제공자에 연결하지 않고, 격리된 NATO 클라우드 안에서 기밀 데이터를 분석하는 보안 생성형 AI 환경도 포함됩니다.

그런데 이 RFP의 입찰지침 10(b)는 제안서 작성에 대해서는 전혀 다른 기준을 둡니다. 공급자 제안서가 전부 또는 일부라도 생성형 AI 도구로 작성된 경우 받아들이지 않겠다고 명시합니다. 챗봇과 ChatGPT 같은 언어 생성 도구를 예로 들고, 발주기관이 AI 사용 여부를 스크리닝할 수 있다고 밝힙니다. 생성형 또는 창작 AI로 작성된 신청서는 추가 검토 없이 거절될 수 있으며 추가 조치도 가능하다고 적었습니다.

여기서 중요한 표현은 “전부 또는 일부”입니다. 본문 전체를 AI가 쓴 경우만 문제가 되는 것이 아닙니다. 요구사항 요약, 영문 번역, 문장 다듬기, 표 작성, Executive Summary 초안처럼 제안서의 일부를 생성형 AI가 만들었다면 적용 대상이 될 수 있습니다. 해당 조항을 발견한 뒤 AI 문장을 사람이 조금 고치는 것으로는 처음의 AI 사용 사실이 사라지지 않습니다.

더 눈여겨볼 점은 사업 자체가 AI를 포함한다는 사실입니다. AI 기술을 납품하라는 요구와 그 계약을 따내기 위한 제안서에 AI를 써도 된다는 허가는 같은 말이 아닙니다. 기술 요구사항과 입찰 행위 규정은 별도로 읽어야 합니다. 이 구분을 놓치면 AI 전문기업일수록 오히려 익숙한 도구를 먼저 사용했다가 적격성 위험을 만들 수 있습니다.

이제 AI 사용 검사는 제안서 작성보다 앞에 있어야 한다

기존 제안 프로세스는 대체로 RFP 접수, 요구사항 분석, Bid/No-Bid, 제안 전략, 집필, 검토, 제출 순서로 움직입니다. 여기에 AI를 붙일 때 많은 조직이 요구사항 분석부터 자동화하려고 합니다. 그러나 NATO 사례가 보여준 순서는 다릅니다.

RFP가 들어온 순간 생성형 AI 사용 상태를 일단 보류해야 합니다. 사람이 원문을 보관하고, 승인된 비생성형 문서 추출 도구로 검색 가능한 텍스트를 만든 다음, AI 사용 관련 조항을 먼저 찾아야 합니다. 자동 파서를 쓰더라도 그 파서는 최종 판단자가 아니라 후보 조항을 찾는 검색 도구여야 합니다. 계약 또는 Bid Manager가 근거 문구와 적용 범위를 확인하기 전에는 RFP를 외부 LLM에 올리거나 AI 요약을 시작하지 않는 것이 안전합니다.

검사 범위도 RFP 본문 하나로 끝나면 안 됩니다. 다음 문서를 하나의 규정 묶음으로 봐야 합니다.

최초 RFP와 Statement of Work
Amendment와 정정 공고
Questions and Answers
Annex, compliance matrix, 가격 양식
제출 포털과 이메일 안내
발주기관의 별도 AI·보안·기밀 정책

실제 NATO 사례도 Amendment 2에 반영된 문서입니다. 최초 공고만 분석하고 이후 변경본을 놓치면 어제까지 허용된 작업이 오늘은 금지될 수 있습니다. 따라서 규정 판정에는 문서 버전과 판정 시각이 반드시 남아야 합니다.

허용·금지·제한만으로 부족하고 판단 보류가 필요하다

운영 시스템에서는 AI 사용 상태를 네 가지로 관리하는 편이 좋습니다.

상태	의미	제안 프로세스 동작
PROHIBITED	생성형 AI 사용이 명시적으로 금지됨	Human-only workflow로 강제 전환
RESTRICTED	특정 작업·도구·환경·공개 조건에서만 허용	승인된 범위만 열고 모든 사용을 기록
ALLOWED	명시적 금지가 없고 내부 정책상 사용 가능	보안·기밀·사실 검증 통제를 적용해 사용
UNDETERMINED	문구가 없거나 해석이 모호하고 확인이 필요함	AI 사용을 잠그고 질의·승인을 기다림

명시적 금지 문구를 찾지 못했다고 곧바로 ALLOWED로 보내면 안 됩니다. “AI”, “generative”, “automated drafting”, “language model”, “machine-generated”, “chatbot”, “authorship”, “original work”처럼 표현이 달라질 수 있고, 별도 보안 정책을 참조할 수도 있습니다. 모호하면 UNDETERMINED가 맞습니다. 낙관적인 자동 추정으로 입찰 자격을 걸 이유는 없습니다.

반대로 모든 사업을 금지로 처리하는 것도 답은 아닙니다. 영국 정부의 PPN 02/24는 조달 과정에서 공급자의 AI 사용을 일률적으로 금지하지 않습니다. 대신 입찰서 작성에 AI를 사용했는지 공개하게 하고, 비공개 발주 정보가 모델 학습에 쓰이지 않도록 비례적 통제를 두며, AI가 포함된 응답에는 추가 실사를 권고합니다. 같은 공공조달이라도 정책은 다릅니다. 그래서 사업별 파싱과 근거 기반 판정이 필요합니다.

파서가 뽑아야 하는 것은 키워드가 아니라 결정 기록이다

좋은 AI 규정 파서는 “AI라는 단어가 세 번 나왔습니다”라고 끝내지 않습니다. 제안팀이 바로 행동을 바꿀 수 있는 결정 기록을 만들어야 합니다.

최소한 다음 항목이 한 화면에 보여야 합니다.

판정 항목	기록할 내용
근거	문서명, 버전, 조항, 페이지, 원문
적용 범위	본문, 번역, 요약, 표, 가격자료, 이메일 등
대상 도구	외부 챗봇, 사내 LLM, 번역·교정·회의록 AI 등
허용 조건	승인된 환경, 데이터 등급, 공개 의무, 사람 검토
위반 효과	부적격, 추가 검토 없는 거절, 계약상 조치 가능성
책임자	판정자, 계약·법무 검토자, 최종 승인자
변경 이력	판정 시각, Amendment 반영 여부, 이전 판정

파서는 조항 위치와 원문을 함께 제시해야 합니다. 요약만 남기면 사람이 해석을 검증할 수 없습니다. NATO의 개정 AI 전략이 강조하는 책임성, 추적 가능성, 신뢰성도 결국 누가 어떤 근거로 판단했는지 재현할 수 있어야 한다는 방향과 맞닿아 있습니다.

금지 사업은 말뿐인 Human-only가 아니라 도구부터 바꿔야 한다

PROHIBITED 판정이 나왔는데 제안팀 채팅방에 “이번 건은 AI 쓰지 마세요”라고 공지하는 것으로는 부족합니다. 평소 쓰던 워드프로세서, 브라우저, 회의 도구에 AI 기능이 이미 들어가 있기 때문입니다. 작성자가 의식하지 못한 채 문장 추천, 요약, 번역, 회의록 생성 기능을 누를 수도 있습니다.

Human-only workflow로 전환할 때는 작업 환경이 함께 바뀌어야 합니다.

첫째, 해당 사업 전용 작업공간에서 LLM, Copilot, AI 번역, 생성형 교정, 회의 요약 플러그인을 차단합니다. 둘째, RFP와 제안 자료를 승인되지 않은 AI 서비스에 붙여넣지 못하도록 접근 정책과 안내를 적용합니다. 셋째, 초안 작성자와 검토자의 실명, 파일 버전, 수정 이력을 남깁니다. 넷째, 외주 집필자와 컨소시엄, 하도급사에도 같은 금지 규정을 계약과 확인서로 전달합니다. 원도급사가 전체 이행 책임을 진다는 점을 생각하면 협력사의 AI 사용도 남의 문제가 아닙니다.

여기서 Human-only는 종이와 펜만 쓰라는 뜻이 아닙니다. 문서 검색, 버전관리, 오피스 편집처럼 승인된 일반 소프트웨어는 사용할 수 있습니다. 다만 내용을 생성하거나 재작성하는 생성형 AI가 제안 산출물에 개입하지 않도록 사람 중심의 작성·검토·승인 경로를 강제하는 것입니다. 어떤 비생성형 도구까지 허용되는지는 해당 RFP와 내부 계약 담당자의 해석으로 확정해야 합니다.

이미 AI를 사용했다면 흔적을 지우려 하지 말고 격리부터 하자

가장 곤란한 상황은 AI 요약과 목차를 만든 뒤 금지 조항을 발견하는 경우입니다. 이때 AI 문장을 사람이 다시 쓰거나 탐지기 점수가 낮아질 때까지 다듬는 방식으로 접근하면 안 됩니다. 적격성 관리의 목적은 AI 사용 흔적을 숨기는 것이 아니라 규정을 준수하는 것입니다.

먼저 AI가 관여한 대화, 초안, 요약, 표를 별도 공간에 격리합니다. 어떤 문서와 데이터가 어느 서비스에 입력됐는지 기록하고, 그 결과가 이후 사람 작성본에 얼마나 영향을 주었는지 범위를 확인합니다. 그다음 Bid Manager와 계약·법무 책임자가 처음부터 사람만으로 다시 작성할지, 발주기관에 질의할지, 입찰을 중단할지 결정해야 합니다.

AI 탐지기 점수는 보조 정보일 뿐 준수 증명이 아닙니다. 조직이 보여줘야 할 것은 사람 작성자, 원자료, 버전 이력, 검토 기록, 도구 접근 로그, 협력사 확인서가 이어지는 작업 계보입니다. 발주기관이 스크리닝할 수 있다는 문구를 봤다면 탐지기를 이기는 방법이 아니라 사람 작성임을 설명할 수 있는 증적을 준비해야 합니다.

제안 조직에 필요한 첫 번째 자동화는 작성이 아니라 통제다

AI를 제안 업무에 붙인다고 하면 대부분 자동 요약과 자동 초안부터 떠올립니다. 하지만 이제 첫 번째 자동화는 AI를 언제 켜고 언제 꺼야 하는지를 결정하는 통제여야 합니다.

RFP 접수 게이트에서 규정 판정이 끝나기 전까지 생성형 AI를 잠그고, PROHIBITED이면 Human-only로 전환하며, RESTRICTED이면 허용된 도구와 작업만 열어야 합니다. Amendment가 들어오면 기존 판정을 자동으로 만료시키고 다시 검토해야 합니다. 제안서 제출 전에는 최종 산출물의 작성 계보와 승인 기록을 적격성 증빙으로 묶어야 합니다.

NIST의 생성형 AI 위험관리 프로필도 조직의 목표와 법적·규제 요구, 위험 허용 범위에 맞춰 관리 방식을 구성하라고 권고합니다. 제안 조직에 적용하면 RFP마다 하나의 AI 사용 프로필을 만드는 셈입니다. “우리 회사는 AI를 적극 활용한다”는 전사 방침보다 “이 입찰에서 이 작업에 이 도구를 써도 되는가”라는 사업별 판정이 우선합니다.

NATO 사례가 던지는 메시지는 단순합니다. AI로 제안서를 더 빨리 쓰는 능력보다, AI를 쓰면 안 되는 제안서를 먼저 알아보는 능력이 입찰에서는 더 중요할 수 있습니다. 이제 생성형 AI 규정 검사는 내부 편의 기능이 아닙니다. 제안서를 제출할 자격을 지키는 입찰 적격성 관리입니다.

이 글은 특정 입찰에 대한 법률 자문이 아니라 제안서 제작 프로세스의 운영 통제를 설명한 글입니다. 실제 판정은 해당 RFP의 최신 Amendment와 Q&A를 기준으로 계약·법무 또는 발주기관 확인을 거쳐야 합니다.