Trajectory 자금 조달, AI 모델 학습의 중심에 도메인 전문가를 세우다

TechCrunch의 11월 2일 AI 학습 자금 조달 보도에 따르면, Trajectory는 기업가치 3억 달러를 기준으로 4,500만 달러를 조달했다. Trajectory 자금 조달의 핵심은 도메인 전문가도 모델 개선에 접근할 수 있도록 하는 데 있다. 관건은 이들이 그에 못지않게 까다로운 평가 업무를 떠안지 않고도 학습을 지시할 수 있는지에 달려 있다.

핵심 경쟁 구도는 전문가 주도 개선과, 모든 비즈니스 수정 사항을 전문가가 학습 결정으로 번역해야 하는 워크플로 사이에 있다. Thinking Machines Lab의 Tinker는 유용한 기준점이다. 이 서비스가 내세우는 대상에는 학습을 직접 제어하려는 연구자와 개발자가 포함된다. Trajectory의 제안은 업무 그 자체에서 전문성을 얻은 실무자까지 확장된다.

이 차이는 엔터프라이즈 AI 팀이 책임을 나누는 방식에 부담을 준다. 변호사는 모델을 학습시키는 방법을 몰라도 용납할 수 없는 답변을 알아볼 수 있다. 엔지니어는 어떤 법적 판단이 지속적인 행동 변화로 이어져야 하는지는 몰라도 학습 인프라를 운영할 수 있다. Trajectory는 소프트웨어가 이러한 역량을 더 직접적으로 연결할 수 있다고 본다.

Trajectory 자금 조달, 도메인 전문가의 역할 확대를 뒷받침하다

의미 있는 변화는 기본 업무를 이해하는 사람에게 모델 개선 결정권을 넘기겠다는 제안에 있다.

이는 컴퓨팅 리소스를 더 쉽게 임대하게 하는 것과는 다른 목표다. 인프라 접근성은 중요하지만, 하나의 수정이 타당한 판단을 반영하는지는 결정하지 못한다. 제품 기회는 오류를 인식하는 일과 그 인식을 신뢰할 수 있는 개선으로 전환하는 일 사이에 있다.

회사의 공개 자료는 플랫폼을 학습, 평가, 배포를 중심으로 설명한다. 팀이 사례를 제공하고, 결과를 검토하며, 언제 변경 사항을 출시할지 결정하는 시스템이라는 것이다. 이는 업무량 감소나 모델 성능 향상에 대한 독립적 증거가 아니라 회사 측 설명이다.

자금 조달은 이 제안이 발전할 여지를 넓힌다. 그러나 고객에게 어느 정도 전문성이 필요한지, 통합에 얼마나 시간이 걸리는지, 개선 사항이 배포 후 얼마나 일관되게 유지되는지는 입증하지 않는다. 이러한 질문은 플랫폼이 참여 범위를 넓히는지, 아니면 기존 기술 팀에 다른 인터페이스만 제공하는지를 결정한다.

재무 수치 역시 신중하게 다뤄야 한다. Trajectory 웹사이트에는 Series A와 시드 투자에 걸쳐 총 6,000만 달러가 표시돼 있다. 이 합산 수치는 보도된 4,500만 달러 라운드와 범위가 다르다. 이를 별도의 자금 조달 이벤트나 모순된 기업가치로 제시해서는 안 된다.

따라서 독자에게 이 자금 조달 소식은 두 층위로 읽힌다. 하나는 초기 인프라 기업에 대한 투자자 지원이다. 다른 하나는 모델이 비즈니스 워크플로에 들어간 뒤 누가 그 모델에 영향을 줄 수 있는지에 관한 제안된 변화다. 엔터프라이즈 구매자에게는 두 번째 층위가 더 오래가는 영향을 미친다.

학습 플랫폼은 기존 개선 프로세스를 더 반복 가능하게 만들 때 제 가치를 한다. 여기에는 수정의 근거를 보존하고, 이를 적절한 사례와 연결하며, 그 결과 변경이 도움이 됐는지 보여주는 일이 포함된다. 매력적인 인터페이스는 이 과정의 일부만 해결한다.

이 발표를 가장 강하게 해석하는 방식은 동시에 가장 좁은 해석이기도 하다. Trajectory는 비즈니스 전문성이 모델 개발에 더 직접적으로 입력되는 제품 범주를 추구하고 있다. 현재 이용 가능한 증거만으로는 모든 조직이 이 과정을 독립적으로 운영할 수 있다고 입증할 수 없다.

이 경계는 중요하다. 접근성은 광범위하게 설명하기 쉽기 때문이다. 제품은 학습 작업을 단순화하면서도 데이터 준비, 승인, 문제 해결은 전문가에게 남겨둘 수 있다. 구매자는 어떤 책임이 제품으로 이동하고 어떤 책임이 팀에 남는지 이해해야 한다.

부담은 전문가와 엔지니어 사이의 인계 과정에 쏠린다

Trajectory의 제안은 학습 작업 자체만큼이나 학습을 둘러싼 조정 업무에 도전장을 던진다.

가상의 법률 워크플로를 생각해 보자. 검토자가 예외 조항에 잘못된 기준을 적용했다는 이유로 AI가 생성한 계약 분석을 수정한다. 이 수정에는 유용한 전문성이 담겨 있지만, 그 의미는 계약서, 관할권, 지침, 비즈니스 맥락에 따라 달라진다.

수정된 답변만 받은 엔지니어링 팀은 불완전한 정보를 갖게 된다. 해당 수정이 일반 규칙을 반영하는지, 고객의 선호인지, 특별한 상황인지 알아야 한다. 이 구분이 없으면 편집 내용을 학습 자료로 전환하는 과정에서 잘못된 교훈을 가르칠 수 있다.

Trajectory의 포지셔닝이 주목하게 하는 것은 바로 이 인계 과정이다. 전문가가 개선 워크플로 안에서 이러한 차이를 표현할 수 있다면, 더 적은 수의 결정이 느슨하게 연결된 문서와 대화를 거쳐 이동하게 된다. 이는 자금 조달 발표가 입증한 결과가 아니라 잠재적인 운영상 이점이다.

내부 AI 팀에 가해지는 압박은 실질적이다. 이들은 도메인 판단, 모델 개발, 출시 권한 사이에 명확한 구분을 마련해야 한다. 기존 역할이 모두 여전히 필요하더라도, 이러한 활동을 더 가깝게 묶는 제품은 조정 요건을 바꾼다.

컨설턴트와 고객사에 상주하는 엔지니어링 팀도 비슷한 질문에 직면한다. 이들의 가치는 부분적으로 고객의 워크플로를 이해하고 이를 기술적 변경으로 전환하는 능력에 달려 있다. 그러한 전환을 표준화하는 소프트웨어는 반복 가능성, 문서화, 필요한 맞춤 작업량에 대한 기대를 높인다.

이 자료만으로 그러한 서비스가 사라질 것이라 예측할 근거는 없다. 일부 조직에는 정리된 사례, 안정적인 평가 기준, 허용 가능한 결과물에 대한 합의가 없다. 그런 환경에서는 까다로운 업무가 학습 실행을 시작하기도 전에 시작된다.

도메인 전문가는 영향력을 얻는 만큼 책임도 얻게 된다. 수정된 답변을 승인할 수 있는 전문 인력이 모델 업데이트를 승인할 준비까지 자동으로 갖추는 것은 아니다. 후자의 결정은 그 전문가가 한 번도 검토하지 않은 사례를 포함해 향후 사례 전반의 행동과 관련된다.

이 차이 때문에 조직 설계는 제품 평가의 일부가 된다. 누가 피드백을 제공하는가? 누가 이견을 해결하는가? 누가 대상 업무 밖의 성능을 점검하는가? 누가 출시를 중단할 수 있는가? 이러한 질문은 더 폭넓은 참여가 더 나은 통제로 이어지는지, 아니면 단지 활동량 증가로 이어지는지를 결정한다.

경제성 판단에도 이 노동을 반영해야 한다. 기술 프로세스가 짧아져도 광범위한 전문가 검토가 필요할 수 있다. 구매자는 자동화가 전체 부담을 줄였다고 결론 내리기 전에 사례 준비, 실패 조사, 업데이트 승인에 필요한 주의를 계산해야 한다.

지식 근로자에게 이 함의는 자금 조달 소식보다 더 직접적이다. 이들의 수정은 일시적 해결책이 아니라 개발 입력값이 될 수 있다. 모호한 편집이 원래 문서를 넘어선 결정에 영향을 줄 수 있으므로, 기록된 추론의 품질은 더 중요해진다.

검색 가능한 의사결정 기록은 이러한 맥락을 보존하는 데 도움이 된다. 이미 기술 자료를 정리하는 팀은 검색 가능한 지식 베이스를 활용해 설명과 뒷받침 문서를 보존할 수 있다. 이러한 기록은 모델 평가를 보완하지만, 학습 사례가 옳다는 점을 입증하지는 않는다.

쉬운 인프라와 쉬운 판단은 서로 다른 제품이다

Tinker와의 비교는 학습 접근성과 타당한 학습 결정에 대한 접근성을 별도로 평가해야 하는 이유를 보여준다.

Thinking Machines는 Tinker를 데이터와 학습 로직을 제어하는 연구자와 개발자를 위한 인터페이스로 설명한다. 이 서비스의 학습 워크플로는 분산 컴퓨팅을 처리하는 한편, 모델이 무엇을 배워야 하는지 지정하는 책임은 사용자에게 남긴다.

애플리케이션 프로그래밍 인터페이스(API)는 소프트웨어가 다른 서비스에 작업을 요청할 수 있게 한다. Tinker는 코드를 통해 학습 기능을 노출하기 위해 이 방식을 사용한다. 문서화된 책임 분담은 학습 프로세스를 설계할 필요를 없애기보다 기술적 제어를 강조한다.

전문가를 대상으로 한 Trajectory의 포지셔닝은 다른 출발점을 향한다. 이 비교는 각 제품이 사용자에게 어떤 책임을 유지하도록 요구하는지에 관한 것이다. 어느 플랫폼이 더 나은 모델을 만든다거나, 모든 고객을 지원한다거나, 다른 플랫폼의 대상 확대를 막는다는 점을 입증하지는 않는다.

연구 팀에게 세부 제어는 핵심 요구 사항일 수 있다. 연구자들은 목표 함수를 수정하거나, 알고리즘을 비교하거나, 예상치 못한 행동을 조사하고자 할 수 있다. 일상 작업을 더 쉽게 만들더라도 이러한 결정을 숨기는 제품은 연구를 방해할 수 있다.

도메인 전문가에게는 같은 제어 기능이 장애물이 될 수 있다. 전문가는 어떤 응답이 적절한지는 알지만 학습 알고리즘을 선택할 이유는 없을 수 있다. 접근 가능한 워크플로는 사용자가 이를 연구용 코드로 표현하도록 요구하지 않으면서 그러한 판단을 보존해야 한다.

이는 까다로운 설계 문제를 만든다. 단순화는 불필요한 결정을 제거하면서도 중요한 결정은 눈에 보이게 해야 한다. 제품이 너무 많은 것을 요구하면 의도한 사용자를 배제한다. 너무 많은 것을 숨기면 사용자는 자신의 선택이 미치는 영향을 이해할 수 없다.

따라서 Trajectory AI 학습이라는 표현은 단순히 작업을 편리하게 시작하는 방식을 넘어선다. 이 약속은 플랫폼이 데이터 선택, 테스트, 출시 전반에 걸쳐 전문성을 전달할 수 있는지에 달려 있다. 각각의 전환 단계는 맥락을 잃을 기회가 된다.

관련 기술적 구분은 정보를 제공하는 것과 행동을 바꾸는 것 사이에 있다. 검색은 외부 문서를 모델의 즉각적인 작업 맥락으로 가져온다. 파인튜닝은 모델의 응답 방식을 바꾸는 추가 학습을 뜻한다. 이 접근 방식은 서로 다른 문제를 해결하며 함께 사용할 수 있다.

새로 업데이트된 정책이 없는 시스템에는 최신 문서에 대한 접근이 필요할 수 있다. 반면 충분한 근거가 있는 정책을 반복적으로 잘못 적용하는 시스템은 다른 문제를 나타낸다. 구매자는 실망스러운 답변마다 추가 학습이 적절한 해결책이라는 증거로 받아들이지 않아야 한다.

이는 불필요한 학습이 추가 업무를 만들기 때문에 상업적으로도 중요하다. 이후 팀은 새 모델 버전을 평가하고 변경 사항에 대한 설명을 유지해야 한다. 접근 가능한 플랫폼은 업데이트 자체를 부추기기보다 적절한 개입을 더 쉽게 식별하도록 해야 한다.

지속되는 경쟁상의 질문은 누가 그 판단을 일관되게 뒷받침할 수 있는가다. 인프라 신뢰성은 여전히 필수적이다. 명확한 증거, 사용 가능한 평가 도구, 이해하기 쉬운 출시 결정도 마찬가지다. 이번 자금 조달 발표는 이러한 역량이 함께 작동해야 하는 시장에 주목하게 한다.

학습 루프는 수정 사항이 실제로 무엇을 뜻하는지에 달려 있다

사용자의 수정은 시스템이 원래 답변을 왜 바꿔야 했는지 보존할 때에만 유용한 학습 증거가 된다.

Trajectory는 지속적 학습을 프로덕션 상호작용과 모델 개선을 연결하는 지속적인 과정으로 설명한다. 웹사이트는 고객이 학습 데이터를 선택하고 평가 및 승인 워크플로를 통해 업데이트를 진행한다고도 밝힌다. 이러한 통제 장치는 고객이 각자의 환경에서 검증하기 전까지는 회사 측 주장에 머문다.

지속적 학습은 추가 경험이 축적됨에 따라 시스템을 업데이트하는 것을 의미한다. 이 표현이 모든 상호작용이 즉각적인 모델 변경을 일으킨다는 뜻은 아니다. 수집, 선별, 학습, 테스트, 승인은 소프트웨어가 이를 연결하더라도 별개의 활동이다.

가상의 재무 분석 사례는 이러한 구분이 중요한 이유를 보여준다. 한 애널리스트는 모델이 부적절한 비교 집단을 사용했다는 이유로 가치평가를 수정한다. 여기서 유용한 교훈은 선별 방법에 관한 것이다. 최종 가치평가만 복사하면 답은 보존되지만 그에 이르는 추론은 사라진다.

또 다른 수정은 그 외에는 수용 가능한 분석의 형식을 바꿀 수 있다. 이 편집은 반드시 실질적 오류를 뜻하지는 않으며, 표현 방식에 관한 선호를 나타낸다. 두 수정을 동일하게 취급하면 학습 목표의 정확성이 떨어진다.

세 번째 수정은 원래 답변 이후 새로 입수된 정보를 따를 수 있다. 모델의 이전 응답은 당시 입력값을 기준으로는 합리적이었을 수 있다. 이를 마치 추론 오류를 저지른 것처럼 학습에 사용하면 실패 원인을 잘못 분류하게 된다.

이 사례들은 보고된 고객 성과가 아니라 분석을 위한 예시다. 수정 사항을 수집하는 일은 시작에 불과한 이유를 보여준다. 유용한 시스템은 어떻게 행동할지 결정하기 전에 누락된 정보, 부실한 추론, 문체적 선호, 상황 변화 등을 구분해야 한다.

전문가 주도 학습에는 의견 불일치를 다룰 방법도 필요하다. 경험 많은 두 검토자가 정당한 이유로 서로 다른 답을 선호할 수 있다. 이들의 판단은 서로 다른 고객, 위험 허용 수준 또는 조직 내 역할을 반영할 수 있다. 맥락 없이 이를 결합하면 일관되지 않은 행동이 생길 수 있다.

인터페이스는 이러한 구분을 이해하기 쉽게 만들어야 한다. 검토자가 한 선호가 폭넓게 적용되는지, 아니면 특정 상황에서만 적용되는지 설명하도록 도와야 한다. 이 지점에서 디자인은 단순히 기술 화면의 탐색을 쉽게 만드는 데 그치지 않고 모델 품질에 영향을 미칠 수 있다.

회사의 웹사이트에는 Clay, Decagon, Harvey의 고객 발언이 포함돼 있다. 이 발언들은 학습, 조정 가능성, 도메인 전문성에 관한 작업을 설명한다. 이는 회사의 포지셔닝과 관계에 대한 근거를 제공하지만, 공통된 독립 성능 측정치는 제공하지 않는다.

Trajectory AI 학습의 경우, 의미 있는 시연은 식별 가능한 실패를 문서화된 개입과 측정된 결과에 연결해야 한다. 독자는 무엇이 바뀌었고 무엇이 유지됐는지, 그리고 평가가 암기를 보상하지 않도록 어떻게 설계됐는지를 이해할 수 있어야 한다.

마지막 지점은 필수적이다. 평가는 모델 행동을 구조적으로 시험하는 과정이다. 그 사례가 학습에 사용된 자료와 겹친다면, 더 높은 점수는 진전을 과장할 수 있다. 더 설득력 있는 결과는 의도한 업무를 대표하는 별도의 사례를 사용한다.

학습 루프는 반복 업데이트를 거치며 이러한 구분을 보존할 때 가치가 생긴다. 성공적인 시연은 고무적이다. 관련 행동을 계속 개선하면서 실수를 드러내는 프로세스는 지속 가능한 엔터프라이즈 제품을 위한 더 강력한 토대다.

인간 참여만으로 신뢰성 문제가 해결되지는 않는다

전문가를 참여시키면 감독의 기회가 생기지만, 그 감독의 품질은 여전히 입증돼야 한다.

검토자는 업데이트의 더 광범위한 영향을 이해하지 못한 채 승인할 수 있다. 대시보드는 어려운 사례를 누락한 채 개선을 표시할 수 있다. 릴리스 프로세스는 검토자가 정보에 근거한 결정을 내릴 만큼 충분한 증거를 확보했는지 보여주지 않은 채 동의 기록만 남길 수 있다.

이는 Trajectory에서 문서화된 실패 사례가 아니라 모델 개선 워크플로의 일반적 위험이다. 플랫폼이 지향하는 접근성은 중대한 결정을 내리는 집단을 넓히기 때문에 중요하다. 검토 도구는 유용한 근거를 통해 이 더 넓은 사용자를 지원해야 한다.

NIST의 AI 위험 프레임워크는 AI 설계, 개발, 사용, 평가 전반에서 신뢰성을 고려해야 할 요소로 다룬다. 이는 유용한 조직적 참고 기준을 제공한다. 이는 Trajectory를 보증하거나 특정 모델 업데이트를 인증하는 것은 아니다.

구매자에게 당장의 질문은 실제로 감독이 어떻게 작동하는가다. 릴리스 검토자는 이전 버전과의 이해 가능한 비교가 필요하다. 그 비교에는 전체 개선 점수만이 아니라 관련 실패, 미해결 문제, 테스트의 한계가 포함돼야 한다.

변경이 이전에 수용 가능했던 행동을 훼손하는지 확인하는 회귀 테스트는 이 비교에 포함돼야 한다. 모델은 학습 대상으로 삼은 작업에서는 개선될 수 있지만 다른 영역에서는 신뢰성이 낮아질 수 있다. 기업은 어떤 절충안을 받아들일지 결정해야 한다.

프라이버시는 별도의 판단 과제다. 운영 환경의 상호작용에는 기밀 문서, 개인정보 또는 상업적으로 민감한 추론이 포함될 수 있다. 답변을 위해 해당 자료를 처리하도록 허용했다고 해서 추가 학습에 사용하도록 허용한 것은 자동으로 성립하지 않는다.

따라서 조직은 접근, 보존, 삭제, 격리에 관한 구체적인 답을 필요로 한다. 이러한 요구 사항은 각자의 계약과 상황에 따라 달라진다. 일반적인 보안 설명만으로는 특정 워크플로가 민감한 사례를 어떻게 다루는지에 대한 모든 질문에 답할 수 없다.

또 다른 불확실성은 이식성이다. 구매자는 플랫폼 사용을 중단할 경우 무엇을 보존할 수 있는지 이해해야 한다. 관련 자산에는 선별된 사례, 평가 사례, 검토자 설명, 과거 의사결정 기록이 포함된다. 이러한 자료를 잃으면 향후 개선을 재현하기가 더 어려워진다.

비즈니스 타당성에는 모델 정확도 이상의 근거도 필요하다. 학습은 측정되는 작업을 개선할 수 있지만 검토 부담을 늘리거나 응답을 늦출 수 있다. 엔터프라이즈 의사결정은 새로운 문제를 조사하고 수정하는 데 필요한 노력을 포함해 전체 워크플로를 고려해야 한다.

이 질문들 중 어느 것도 Trajectory 펀딩이 제시하는 기회를 무효화하지는 않는다. 이는 그 기회를 평가하는 데 필요한 근거를 규정한다. 고객이 결과로 생긴 변화를 이해하고, 관리하고, 재현할 수 있을 때 학습 접근성을 높이는 일은 상업적으로 의미가 있다.

따라서 가장 강력한 회의적 입장은 구체적이다. 현재 공개된 발표는 비기술 전문가가 다양한 운영 환경에서 신뢰할 수 있는 모델 개선을 독립적으로 유지할 수 있음을 입증하지 않는다. 이는 고객 배포와 투명한 평가를 통해 검증돼야 할 주장으로 남아 있다.

독립적인 결과, 고객 자립성, 반복 업데이트를 주시하라

다음으로 유용한 근거는 전문가 주도 개선이 세심하게 지원된 시연을 넘어 작동하는지를 보여줘야 한다.

앞으로 몇 달간 세 가지 신호를 명확한 순서로 주목할 필요가 있다. 첫째는 대표적인 업무에서의 측정 가능한 성과다. 둘째는 고객이 여전히 필요로 하는 전문 지원의 규모다. 셋째는 반복 업데이트를 거쳐서도 프로세스가 신뢰성을 유지한다는 근거다.

첫 번째 신호는 명확한 기준선이 있는 고객 뒷받침 평가다. 기준선은 변화를 비교하는 출발 시스템이다. 기준선이 없으면 개선 주장은 학습이 기존 워크플로에 비해 가치를 더했는지 독자가 판단할 수 없게 만든다.

유용한 결과는 작업, 평가 방법, 결론의 범위를 설명한다. 제공업체의 주장과 고객 측정을 구분한다. 또한 실패 사례도 보여준다. 한계가 없는 협소한 성공은 다른 조직에 거의 지침을 제공하지 못하기 때문이다.

별도의 평가 사례가 의도한 업무에서 일관된 향상을 보인다면 이는 Trajectory의 주장을 강화할 것이다. 개선이 선별된 시연 밖에서 사라진다면 광범위한 주장은 약화될 것이다. 어느 결과도 실제로 테스트된 조건을 넘어 일반화해서는 안 된다.

두 번째 신호는 고객 자립성이다. 공개 인터페이스만으로는 도메인 전문가가 워크플로를 운영할 수 있음을 보여주지 못한다. 중요한 근거는 누가 사례를 준비하고, 문제를 조사하고, 평가 기준을 결정하고, 결과 모델을 승인하는지에 관한 것이다.

상세한 고객 사례는 기밀 데이터를 공개하지 않고도 이러한 업무 분담을 명확히 할 수 있다. 전문가가 어떤 작업을 완료했고 기술 전문가가 어디에 개입했는지 설명할 수 있다. 이는 성공적인 학습 실행에 대한 설명보다 접근성 주장을 더 구체적으로 만들 것이다.

제한된 맞춤형 지원만으로 반복 가능한 운영을 보여주는 근거는 제품 가설을 뒷받침할 것이다. 계속해서 집중적인 전문 작업에 의존한다면 그 범위는 좁아질 것이다. 그렇다고 플랫폼이 쓸모없어지는 것은 아니지만, 포지셔닝이 암시하는 대상과 경제성은 달라질 것이다.

세 번째 신호는 가시적인 통제를 갖춘 반복 개선이다. 한 번 좋은 성과를 내는 모델 버전보다, 결과가 문서화된 일련의 업데이트가 더 많은 것을 입증한다. 기록에는 업데이트가 실패했을 때 무엇이 발생했는지, 팀이 이를 진단하고 되돌릴 수 있었는지도 보여줘야 한다.

이전의 정상 작동 버전을 복원하는 롤백은 릴리스가 예상치 못한 행동을 유발할 때 특히 유익한 정보가 된다. 구매자는 이해하기 쉬운 복구 절차와 보존된 근거를 찾아야 한다. 신뢰성에는 단순히 변경을 릴리스하는 능력뿐 아니라 실수에 대응하는 능력도 포함된다.

경쟁사의 발전은 세 신호 모두에 맥락을 제공할 것이다. 연구 중심 학습 서비스는 사용성을 개선할 수 있고, 전문가 대상 플랫폼은 기술적 통제를 추가할 수 있다. 제품 범주는 광범위한 접근성 언어가 아니라 실제 고객의 책임을 통해 더 분명해질 것이다.

현재로서는 Trajectory 펀딩이 구체적인 엔터프라이즈 AI 질문을 부각한다. 결과를 수정하는 사람들이 지속적인 개선도 지시할 수 있는가? 답은 그들의 판단을 신뢰할 수 있는 행동과 연결하는 근거에 달려 있다. 펀딩과 인터페이스 디자인은 그 노력을 지원하지만, 어느 쪽도 입증된 결과를 대신하지는 않는다.

팀이 반복되는 AI 실수를 이미 기록하고 있는 워크플로부터 시작하라. 각 수정이 무엇을 의미하는지, 누가 이를 검증할 수 있는지, 별도의 사례에서 성공을 어떻게 테스트할지를 물어라. 그런 다음 그 근거를 전문가 대상 학습 플랫폼이 제공하도록 요구하는 사항과 비교하라. 어려운 사례와 상충하는 검토자 판단을 포함한 대표 업무를 사용해 시연을 요청하라. 이전 버전과 제안된 업데이트를 함께 살펴보고, 실패한 릴리스를 팀이 어떻게 되돌릴지 물어라. 이후의 개선도 설명 가능하도록 의사결정 기록을 보존하라. 현재 프로세스에서 진전을 제한하는 요소는 무엇인가? 학습 인프라에 대한 접근성, 이용 가능한 사례의 품질, 아니면 더 나은 답이 실제로 어떤 모습인지에 대한 합의인가?