Which AI startups actually land enterprise contracts? — Brian Lewis, Millennium

한 줄 핵심

기업 계약을 따내는 AI 스타트업은 모델 성능보다 보안·권한·감사·배포 통제 같은 ‘지루한 60%’를 먼저 갖춘 팀이며, 이를 못 맞추면 데모와 파일럿은 통과해도 계약으로 이어지지 않는다.

시간별 요약

1. 0:00
   판매자와 구매자가 같은 자리 기업용 AI를 논할 때는 스타트업의 판매자 관점과 엔터프라이즈의 구매자 관점을 함께 봐야 하며, 실제로는 내부 시스템과 운영 제약이 계약 성사에 큰 영향을 준다. 현재 모델 지능 수준에서는 AI가 만들어낼 수 있는 가치가 아직 많이 남아 있고, 그 가치 실현은 모델과 제품만이 아니라 기업 내부 구조까지 포함한 AI 네이티브 전환에 달려 있다.
2. 2:52
   퍼널과 계약으로 이어지는 5% 문제 하나당 10~15개 스타트업을 검토해도 데모는 2~3개만 진행되고, 파일럿은 0~1개, 장기적으로 계약까지 가는 비율은 데모의 약 5% 수준에 불과하다. 이 과정에서 가장 많이 탈락하는 이유는 효용성, 보안, 신뢰성, 법적 요건이 기업 기준을 충족하지 못하기 때문이다.
3. 4:16
   효용성과 가격을 문제에 맞게 설계하기 제품은 실제 문제를 해결해야 하고, 가격은 그 실제 가치에 맞아야 하며, 통합은 첫날부터 검증 가능해야 한다. 데모는 그럴듯하지만 내부 팀이 6주 만에 다시 만들 수 있는 수준이거나, telemetry를 자기 가격 산정에 쓰겠다고 요구하는 식의 역설적 가격 구조는 통하지 않는다.
4. 5:36
   파일럿 기간이 몇 달에서 몇 주로 예전에는 6개월짜리 파일럿도 가능했지만, 이제는 3개월을 거쳐 2주까지 압축될 정도로 의사결정 속도가 빨라졌다. 그만큼 판매자는 고객이 요구한 사항을 우선 해결해야 하며, 이미 거절된 기능을 다시 제안하는 방식은 신뢰를 깎는다.
5. 6:57
   구매자 측 보안 요구 사항 ZDR, customer-managed encryption keys, BYO gateway, BYO infrastructure, SCIM-tied RBAC, API 기반 설정 제어, 최소 1명의 실제 보안 인력 보유가 핵심 요구로 등장한다. 엔터프라이즈는 기능을 모두에게 일괄 개방하는 방식을 원하지 않으며, 권한과 배포를 세밀하게 통제할 수 있어야 한다.
6. 8:19
   보안에서 반복적으로 실패하는 지점 가장 흔한 실패는 고객 데이터를 벤더 서버로 보내면서도 요구사항을 지키지 않는 것과, read write all 같은 과도한 권한을 요구하는 것이다. 베타 기능을 기본 활성화하거나, 보안 아키텍처 다이어그램을 미루고, 침해 사고 대응 계획이 없는 상태도 기업 입장에서는 명확한 경고 신호다.
7. 9:42
   신뢰성, 제어 평면, 감사 로그 관리 설정을 API로 제어할 수 있어야 하고, 설정 변경에 대한 audit log가 남아야 하며, 실질적인 SLA와 즉시 연락 가능한 지원 엔지니어가 중요하다. 잦은 배포로 버전이 갈라지거나 SSL certificates가 깨져도 추적이 안 되면 운영 환경에서는 사용할 수 없다.
8. 11:04
   거래일 중 발생한 장애 핵심 API가 바쁜 거래일에 수 시간 동안 다운되면, 수십억 달러를 운용하는 환경에서는 치명적인 문제로 이어진다. status page와 SLA 로드맵이 없으면 장애 대응과 신뢰 회복이 더 어려워진다.
9. 12:23
   법무, 보존 조항, 4차 위험 고객 데이터로 학습하지 않아야 하고, sub processor와 fourth-party risk를 투명하게 드러내야 하며, IP indemnification과 합리적 책임 한도가 필요하다. ZDR를 주장하면서 실제로는 데이터를 보관하거나, beta 기능에만 느슨한 보존 조항을 숨겨 두는 방식은 계약 리스크를 크게 높인다.
10. 13:44
    11일마다 나오는 모델, 10년 된 아키텍처 새로운 frontier model은 평균 11일마다 나오지만, 기업 내부 아키텍처는 10년 넘게 낡은 상태일 수 있어 변화 속도가 매우 비대칭적이다. AI 모델과 제품은 레거시 아키텍처나 변화관리 자체를 해결하지 못하며, 그 사이의 보안·프라이버시·운영 복잡성이 실제 병목이 된다.
11. 15:07
    화려하지 않은 60% AI 네이티브 전환의 절반 이상은 AI 자체보다 데이터 정비, 깨끗한 아키텍처, 통합, 교육, 변화관리 같은 기본기에 달려 있다. AI는 문제를 가리는 반창고가 아니라 기존 구조의 상태를 비추는 손전등이어서, 기반이 약하면 오히려 더 빨리 무너진다.
12. 16:28
    권한 체계와 에이전트가 문제를 증폭시키는 이유 에이전트 시대에는 entitlements를 새롭게 설계해야 하며, cross-platform integration과 중앙화된 지식 기반이 더 중요해진다. 에이전트는 기존 권한과 거버넌스를 그대로 상속하므로, 현재도 잘 안 되는 권한 체계는 에이전트가 들어오면 훨씬 더 큰 문제로 커진다.
13. 17:54
    양쪽 모두를 위한 실행 원칙 스타트업은 대형 엔터프라이즈가 요구하는 보안, 규제, 배포 통제, 감사 체계를 처음부터 설계해야 하고, 구매자는 entitlements, governance, audit logging 같은 기본기를 먼저 정비해야 한다. 결국 기업용 AI의 성패는 기술의 화려함보다 운영 가능한 구조를 얼마나 먼저 갖추느냐에 달려 있다.

실무 인사이트

• AI 스타트업은 데모 완성도보다 ZDR, 권한 제어, audit log, SLA 같은 엔터프라이즈 필수 요건을 먼저 제품 요구사항으로 고정해야 계약 전환율이 올라간다.
• 구매자는 AI 도입 전에 entitlements와 데이터 구조를 정리해야 하며, 기존 운영 체계가 허술하면 에이전트 도입은 문제를 더 크게 증폭시킨다.
• 파일럿 기간이 짧아진 만큼 초기 2주 안에 통합 가능성, 보안 통과, 운영 제어 가능성을 증명하지 못하면 후속 논의가 빠르게 사라진다.