파일럿은 잘 작동했다. 그것은 애초에 문제가 아니었다. 데모는 성공적이었고, 정확도는 방어할 만했고, 사용자들도 좋아했다. 그리고 그것은 대기열에서 다섯 달을 보낸 뒤 조용히 언급되지 않게 되었다. 아무도 그것을 죽이지 않았다. 그저 유효기간이 만료되었을 뿐이다. 이런 일을 두 번 겪었다면 아마 조직이 망가졌다고 결론 내렸을 텐데, 나는 덜 만족스러운 설명을 제시하고 싶다. 그 파일럿은 아무도 막혀 있지 않던 질문에 답하도록 설계되어 있었다는 것이다.

데모는 "이 모델이 이 일을 할 수 있는가?"에 답한다. 조직은 그것에 대해 확신이 없었던 적이 없다. 조직이 모르는 것은 모델이 틀렸을 때 누가 책임지는지, 데이터가 어디로 가는지, 갱신 시점에 무슨 일이 벌어지는지, 누가 서명하는지다. 이런 질문들에는 저마다 소유자가 있고, 그 소유자들에게는 저마다 대기열이 있으며, 그중 누구도 당신의 파일럿이 오는 것을 예상하지 못했다.

구매팀은 악당이 아니다

엔지니어링 쪽의 해석은 구매 절차가 일종의 세금이라는 것이다. 위험을 회피하려는 사람들이 명백한 가치를 지연시킨다는 것. 그 해석은 편하지만 대체로 틀렸고, 그것을 고수하는 데는 비용이 든다. 정당하지 않다고 판단해버린 프로세스를 우회해서 설계할 수는 없기 때문이다.

구매팀은 이 회사가 이것과 3년을 함께 살 수 있는지 묻는 기능이다. 그들이 던지는 모든 질문은 이전에 있었던 사건, 대개는 당신이 오기 전에 벌어진 사건을 담고 있다. 인수되어 가격을 세 배로 올린 벤더. 무엇을 보관하고 있는지 목록이 없어서 아무도 범위를 파악할 수 없었던 데이터 유출 사고가 있는 도구. 두 사람만 쓰던 제품인데 자동 갱신되어버린 계약. 당신의 양식을 검토하는 사람에게 이것들은 가정이 아니다. 그 양식이 존재하는 이유다.

마찰은 실재하고, 그중 일부는 정말로 낭비다. 하지만 느린 게이트에 대한 올바른 대응은 그것이 없기를 바라는 것이 아니라, 좋은 답을 준비해서 일찍 들어가는 것이다.

실제로 진행을 멈추게 하는 네 개의 게이트

보안 검토

설문지는 사실 벤더의 TLS 설정에 관한 것이 아니다. 그 도구가 어디까지 접근할 수 있고 오작동했을 때 무슨 일이 벌어지는지를 확인하려는 것이다. AI 도구는 구조적인 이유로 여기서 낮은 점수를 받는다. 쓸모 있으려면 광범위한 읽기 권한을 요구해야 하기 때문이다. "테넌트 안의 모든 문서를 읽어서 그에 대한 질문에 답할 수 있게 한다"는 정당한 제품 요구사항이면서 동시에 진심으로 우려스러운 접근 요청이며, 이 두 가지는 동시에 참이다.

이 게이트를 통과하는 파일럿은 자신의 권한 모델을 한 문장으로 말할 수 있는 파일럿이다. 기본은 읽기 전용이고 쓰기 권한은 별도로 명시적 동의를 거치는 단계로 두는 것은, 감사 로그가 아무리 훌륭해도 두 가지를 다 하는 단일 스코프보다 근본적으로 검토가 쉽다. 도구가 자신의 폭발 반경을 설명하지 못한다면, 보안팀은 그것을 알아낼 것이다. 천천히, 문서로, 6주에 걸쳐서.

데이터 처리 계약

대부분의 AI 파일럿이 실제로 죽는 곳이 바로 여기이며, 질문 하나에서 죽는다. 우리 데이터가 당신들 모델을 훈련하는 데 쓰이는가?

답이 한 문단을 필요로 한다면, 그것은 사실상 그렇다는 답이고, 법무팀도 그렇게 읽을 것이다. DPA에는 하위 처리자가 명시되어 있어야 하고, 보존 기간이 일수로 명시되어 있어야 하고, 계약 종료 시 삭제가 명시되어 있어야 하고, 훈련 관련 질문이 한 개의 조항으로 답해져 있어야 한다. 얼버무릴 때마다 검토 사이클이 하나씩 추가되고, 검토를 맡은 사람에게는 다른 마흔 가지 일이 있기 때문에 검토 사이클은 각각 2주씩 걸린다.

여기에 문제를 가중시키는 것은 AI 벤더들이 DPA 주기가 가정하는 것보다 하위 처리자를 훨씬 자주 바꾼다는 점이다. 모델 제공자 교체는 곧 수정 계약이 된다. 아무도 그 수정 계약을 계획해두지 않는다.

AI 전용 오버레이

대략 작년부터 새로 생긴 것이고, 적용 방식은 일관되지 않다. 위험 분류, 인간 감독에 대한 설명, 자신의 의무를 알고 있다는 증거를 요구하는 내부 AI 검토다. 이것이 존재하는 곳에서는 대개 가장 빠른 게이트인데, 아직 새로워서 담당자에게 시간이 있기 때문이다. 아직 존재하지 않는 곳에서는, 그 질문들이 어쨌든 비공식적으로, 눈치챈 아무나에 의해, 최악의 순간에 던져진다. 8월 2일 투명성 의무가 다가오면서 이 게이트가 더 많은 곳에서 공식화되리라 예상되며, 그것이 개선이 되리라 예상해도 좋다. 정의된 게이트와 대기열이, 운영위원회에서 즉흥적으로 제기되는 정의되지 않은 반대 의견보다 낫기 때문이다.

예산 소유권

가장 조용한 살인자다. 파일럿은 누군가의 재량 예산이나 무료 티어로 운영된다. 프로덕션에는 예산 항목, 비용 센터, 그리고 다음 주기에 그것을 방어해줄 소유자가 필요하다. 파일럿의 스폰서가 예산 보유자가 아니라 열정적인 엔지니어라면, 결과와 무관하게 파일럿에서 프로덕션으로 가는 경로는 없다. 그리고 이것은 대개 살펴보는 사람에게는 첫날부터 보인다.

파일럿 자체가 함정을 놓는 이유

파일럿은 시작하기 쉽도록 설계되며, 시작을 쉽게 만드는 바로 그 요소들이 끝맺음을 불가능하게 만드는 요소들이다. 합성 데이터나 정제된 데이터라서 DPA 질문이 아예 떠오르지 않는다. 샌드박스 테넌트라서 접근 모델이 검토되지 않는다. 무료 티어라서 예산 소유자가 필요 없다. 열정적인 팀이라서 책임 소재 질문이 나오지 않는다.

이런 선택 하나하나는 게이트를 통과시키는 것이 아니라 미루는 것이다. 그러다 파일럿이 성공하면 그 네 가지가 한꺼번에 들이닥친다. 다들 어려운 부분은 끝났고 남은 일은 서류 작업뿐이라고 믿고 있을 바로 그 순간에. 조직은 프로덕션 쪽으로 단 1밀리미터도 움직이지 않았고, 이제는 실망까지 더해진다.

파일럿을 게이트에 맞춰 설계하라

해법은 파일럿에 거버넌스를 더 넣는 것이 아니다. 성공했을 때 배포를 가로막는 질문들에 답이 되는 파일럿을 고르는 것이다.

  • 가능한 한 가장 작은 범위에서, 실제 테넌트의 실제 데이터를 사용하라. 부서 하나, 프로덕션 데이터, 실제 권한 모델. 사용자 세 명과 실제 데이터로 하는 파일럿은 사용자 삼백 명과 합성 데이터로 하는 파일럿보다 더 많은 게이트를 통과한다. 약속이 아니라 답을 만들어내기 때문이다.
  • DPA는 12주차가 아니라 1주차에 검토받아라. 데모 전에 법무팀에 보내라. 훈련 관련 조항이 문제라면, 분기 전체가 아니라 이메일 한 통 값으로 결과를 미리 알게 되는 것이다.
  • 시작하기 전에 예산 소유자를 정하라. 예산 항목을 소유할 사람이 아무도 없다면, 그 파일럿을 연구로 운영하고 그렇다고 공개적으로 말하라. 그것은 정당한 선택이다. 정당하지 않은 것은 그것을 프로덕션으로 가는 경로라고 부르는 것이다.
  • 설문지가 도착하기 전에 보안 답변을 작성해두라. 권한 모델, 데이터 흐름, 하위 처리자, 보존, 삭제. 한 페이지면 된다. 6주 지연의 대부분은 왕복 시간이고, 왕복 시간은 지연이지 실제 작업이 아니다.
  • 게이트는 빌드와 병행해서 돌려라. 게이트는 노력이 아니라 대기열에 좌우된다. 법무팀이 DPA를 읽는 데 당신의 코드가 존재할 필요는 전혀 없다.

이렇게 하면 파일럿을 시작하는 속도는 느려지지만 끝을 볼 가능성은 극적으로 높아진다. 이 교환은 하나를 잃어본 뒤에야 비로소 명확해진다. 반론도 타당하다. 탐색적인 작업에 게이트를 앞당겨 얹으면 탐색 자체가 죽는다. 그리고 어떤 파일럿은 빠르게 죽어도 괜찮은 저렴한 실험으로 남는 편이 낫다. 좋다. 다만 당신이 어느 쪽을 운영하고 있는지 정직하게 밝혀라. 내가 말하는 실패는 나쁜 실험이 아니기 때문이다. 그것은 모두가 배포 계획이라고 착각한 좋은 실험이다.

핵심 정리

AI 파일럿은 정확도 때문에 죽는 경우가 거의 없다. 데모가 아무도 막혀 있지 않던 질문에 답하는 동안, 보안 검토와 DPA와 AI 오버레이와 예산 소유권은 마지막까지 손대지 않은 채 방치되었다가 한꺼번에 들이닥치기 때문에 죽는다. 구매 절차는 방해물이 아니다. 그것은 조직이 이것과 3년을 함께 살 수 있는지 묻는 과정이며, 그 질문들은 당신이 일정에 넣었든 넣지 않았든 어차피 온다. 성공이 곧 게이트 통과를 의미하도록 파일럿을 설계하라. 출시하는 팀은 더 좋은 모델을 가진 팀이 아니다. 1주차에 12주짜리 시계를 돌리기 시작한 팀이다.

다음으로 읽을 글

플랫폼 마이그레이션이 왜 똑같은 대기열에서 멈추는지를 다루는, 이 이야기의 인프라 버전은 ercan.cloud의 필드 노트에 있다. 허브는 ercanermis.com이다.