Where Projects Become Outcomes

"프로젝트를 성과로 전환하다"

ai계약 12

지운다던 프롬프트가 30일을 남는다 - AI 계약의 데이터 보존 조항은 누가 정하는가

HFC 이슈 브리핑 · BRIEF 18지운다던 프롬프트가30일을 남는다.AI 계약의 데이터 보존 조항은 누가 정하는가 · HFC Consulting계약서에 한 줄이 있었다. 프롬프트와 응답은 처리 후 보존하지 않는다. 정보보호 담당자가 붉은 펜으로 표시하고, 법무 검토를 거쳐 살아남은 문장이었다.지난주, 그 한 줄의 값이 벤더 쪽에서 움직였다. 발주기관은 협상 테이블에 앉지도 않았다.이슈 요약2026년 8월 19일, 오픈AI가 프런티어 모델 API 고객을 대상으로 무보존(Zero Data Retention) 원칙을 유지하면서 오용을 탐지하는 '프라이빗 세이프티 프로세싱'을 공개했다. 데이터는 고객이 통제하는 인프라에 두거나, 고객이 암호키를 쥔 상태로 오픈AI 저장소에 둔다. 오픈AI가 회수하는 것은 제..

AI가 만든 결함, 책임은 누가 지는가 (06/08)

AI 시대의 분쟁·클레임 대응 · Ep.06결함은 발견됐다.작성자는 발견되지 않았다.AI가 만든 결함, 책임은 누가 지는가 · HFC Consulting운영 넉 달째, 정산 배치가 오류를 냈다. 원인 코드를 추적하던 운영팀이 이상한 지점에 닿았다. 그 구간의 작성자를 아무도 몰랐다. 개발 당시 AI 도구가 생성한 코드였고, 리뷰 기록은 없었다. 발주기관이 물었다. "이 결함의 책임은 누구에게 있습니까."낯익은 질문이다. 다만 이번에는 답하기 위한 계약 조항이 없다(그 코드는 누가 짰습니까?).질문 자체는 낡았다. 하자의 책임, 결함의 귀책은 이 연재가 내내 다뤄 온 주제다. 새로운 것은 등장인물이다. 작성자가 사람이 아닐 때, 검증의 관행과 책임의 언어가 계약에 없다는 사실이 드러난다.양측의 주장: 산출..

AI 활용 조건에 답하기: 약속해도 되는 것과 안 되는 것 (06/08)

AI시대의 제안서 작성 가이드 · Ep.06지킬 수 없는 약속은제안서에서 계약서로 옮겨 간다.AI 활용 조건에 답하기: 약속해도 되는 것과 안 되는 것 · HFC ConsultingRFP에 이런 조항이 있다. "수급인은 본 사업 수행 시 생성형 AI 도구 사용 내역을 전건 기록하고, 발주기관의 요청 시 제출하여야 한다." 제안 팀은 잠시 침묵한다. 개발자 마흔 명이 하루에 수백 번 쓰는 도구의 사용 내역을, 전건, 기록한다.이런 조항에 "준수하겠습니다" 세 글자로 답하는 것이 가장 쉬운 선택이다. 그리고 그 세 글자는 제안서에서 계약서로, 계약서에서 검수 항목으로 옮겨 간다. 이행할 수 없는 약속은 수주가 아니라 채무다.발주자는 왜 이런 조건을 쓰는가6기 Ep.05 (AI 활용 조건, RFP에 먼저 쓴다..

AI 활용 조건, RFP에 먼저 쓴다 (05/08)

발주자를 위한 RFP 가이드 · Ep.05계약 테이블에서 처음 나온 질문은이미 늦은 질문이다.AI 활용 조건, RFP에 먼저 쓴다 · HFC Consulting우선협상 대상자와의 첫 회의였다. 발주 담당자가 물었다. "개발에 생성형 AI를 씁니까." 제안사 PM이 되물었다. "제안요청서에는 관련 조건이 없었습니다만." 둘 다 맞는 말이었다. 그래서 문제였다.이번 화는 AI 활용 조건을 계약이 아니라 RFP 단계에서 요구하는 방법이다. 도구와 데이터와 권리, 세 조건이 공고문에 먼저 실려야 하는 이유와 실을 때 쓸 문구를 다룬다.협상에서 처음 꺼내면 늦는 세 가지 이유첫째, 가격에 반영되지 않는다. 데이터 반출 금지, 승인 도구 한정 같은 조건은 수급인의 원가에 영향을 준다. 낙찰 후에 꺼내면 조건은 "추..

서명 전 마지막 점검 - AI 계약 체크리스트 총정리 (08/08)

발주자를 위한 AI 계약 가이드 · Ep.08 (완결)서명하기 전,여덟 줄만 확인한다.서명 전 마지막 점검 — AI 계약 체크리스트 총정리 · HFC Consulting계약서 최종본이 도착했다. 서명은 내일 오전이다. 조항 전체를 처음부터 다시 읽을 시간은 없다. 법무 검토는 끝났지만, 법무의 관점은 법률 리스크이지 사업 리스크가 아니다. AI와 관련해 사업 담당자가 직접 확인해야 할 항목이 있다. 이 연재의 일곱 편을 그 목적에 맞게 한 장으로 압축했다.계약의 진행 순서대로 따라가면 된다. RFP에서 유지보수까지, 여덟 줄이다.단계별 종합 체크리스트단계확인 질문근거 편1. RFPAI 도구·공정·데이터의 3요소 고지 요구가 있었는가, 그 답변이 계약 문서에 편입되는가Ep.022. 대가검증·보안·문서화 공..

우리 데이터가 남의 AI를 학습시키고 있다면... (07/08)

발주자를 위한 AI 계약 가이드 · Ep.07우리 데이터가남의 도구 안에 있다.우리 데이터가 남의 AI를 학습시키고 있다면 · HFC Consulting개발자가 재현되지 않는 오류를 붙잡고 있다. 원인 파악이 늦어진다. 그가 운영 데이터 한 조각을 복사해 AI 채팅창에 붙여넣는다. "이 데이터에서 왜 오류가 발생하는지 분석해줘." 오류는 잡힌다. 그 데이터에 고객 계좌번호가 포함되어 있었다는 사실은 아무 기록에도 남지 않는다. 유출 신고도, 보고도 없다. 유출이라는 자각 자체가 없었기 때문이다.악의가 아니라 습관이다. 습관이기 때문에 더 자주 일어난다. 계약이 이 장면을 다뤄야 하는 이유다.비밀유지 조항이 잡지 못하는 이유기존 계약서에도 비밀유지 조항은 있다. 그러나 그 조항이 상정하는 유출은 사람이 사..

AI가 만든 하자, 누가 보증합니까? (06/08)

발주자를 위한 AI 계약 가이드 · Ep.06AI가 만들었어도,보증은 사람이 한다.AI가 만든 하자, 누가 보증합니까 · HFC Consulting시스템 오픈 3주 차, 월말 정산 배치가 중단됐다. 원인은 날짜 경계를 잘못 처리한 로직. AI 도구가 생성한 코드였다. 하자보수 회의에서 수급인 담당자의 말끝이 흐려진다. "그 부분은 저희 개발자가 직접 작성한 것이 아니라서 원인 파악에 시간이 필요합니다." 발주 담당자가 계약서를 편다. 하자담보책임 조항에 AI에 관한 언급은 없다. 있어야 하는가. 1기 7화에서 던진 질문이 현실이 된 장면이다.원칙은 단순하다. 도구는 책임의 주체가 될 수 없다. 계약 당사자가 책임을 진다. 계약서가 할 일은 이 단순한 원칙에 예외가 생기지 않도록 문장을 세워 두는 것이다...

검수 기준 다섯 줄, 계약서에 이렇게 넣습니다 (05/08)

발주자를 위한 AI 계약 가이드 · Ep.05검수 기준 다섯 줄이면 된다.서명 전이라면.검수 기준 다섯 줄, 계약서에 이렇게 넣습니다 · HFC Consulting납품 검수 회의. 시연이 끝나고 전 기능이 정상 동작한다. 검수확인서에 도장이 찍힌다. 여섯 달 뒤, 기능 추가 요청이 들어오고 개발자가 그 코드를 연다. 구조가 복잡하게 얽혀 있어 손대는 데 일주일이 걸린다. 발주 담당자가 검수확인서를 다시 꺼내 읽는다. 어디에도 코드의 구조를 본다는 말은 없다. 기능이 동작하는 것과 코드가 건강한 것은 다른 문제인데, 계약서는 앞의 것만 물었다.1기 6화의 결론은 "검수 기준은 계약 전에 합의해야 한다"였다. 이번 편은 그 합의를 조항 문구로 완성한다."검사에 합격하여야 한다"의 공백표준 계약서의 검수 조항..

프롬프트도 납품물입니까? (04/08)

발주자를 위한 AI 계약 가이드 · Ep.04코드는 남았다.의도는 사라졌다.프롬프트도 납품물입니까 · HFC Consulting운영 이관 후 여섯 달. 유지보수 수급인이 소스코드를 연다. 인증 로직이 통상의 구조와 다르게 짜여 있다. 왜 이렇게 설계했는지 확인할 문서가 없다. 설계서에는 해당 내용이 없고, 담당 개발자는 퇴사했다. 그 판단은 어느 오후의 프롬프트 창에서 이루어졌고, 그 창은 닫혔다. 유지보수 수급인은 구조 분석에만 3주를 쓴다. 그 3주의 비용은 발주자가 낸다.1기 3화에서 진단한 문제다. 이번 편은 그 진단을 계약 조항으로 옮긴다.산출물 목록은 프로젝트의 유산 목록이다프로젝트가 종료되면 인력은 떠나고 산출물만 남는다. 계약서의 산출물 목록은 결국 "발주 조직에 남을 유산의 목록"이다. ..

AI로 반값이 됐다는데, 왜 견적은 그대로입니까? (03/08)

발주자를 위한 AI 계약 가이드 · Ep.03개발비는 줄었다는데,총액은 왜 그대로인가.AI로 반값이 됐다는데, 왜 견적은 그대로입니까 · HFC Consulting견적 협상 자리. 발주 담당자가 기사 하나를 테이블에 올린다. AI 도입으로 개발 생산성이 배가 되었다는 내용이다. "이 정도면 견적이 달라져야 하는 것 아닙니까." 수급인 측 임원이 답한다. "빨라진 것은 코딩이고, 저희가 납품하는 것은 시스템입니다." 양쪽 모두 틀린 말이 아니다. 문제는 계약서의 대가산정 방식이 이 논쟁을 정리할 언어를 갖고 있지 않다는 데 있다.투입 공수(M/M) 단가표는 사람이 코드를 작성하던 시기의 통화다. 그 전제가 흔들리면, 단가표의 신뢰도 함께 흔들린다.투입 공수 산정의 균열동일한 화면 하나를 개발자 A는 AI ..