About 5% of enterprise AI demo calls end in a signed contract, because most opportunities fail on efficacy, security, reliability, or legal terms.
2
Enterprise buyers expect deployable integrations, controlled permissions, audit logs, support, data retention clarity, and pricing tied to real value.
3
Brian Lewis argues that 60% of becoming AI native is work on data hygiene, architecture, integration, enablement, change management, and entitlements.
Summary
Brian Lewis explains enterprise AI buying from the perspective of a buyer at Millennium, while speaking personally rather than for his employer. For one internal pain point, he may review 10 to 15 startups, book two or three demos, run zero or one pilot, and sign about one contract for every four pilots. The talk examines where the other opportunities fail. A product must solve the stated problem, show real integrations, price against value, and meet requirements for security, reliability, and legal terms. Lewis gives examples of excessive access scopes, undocumented changes, missing audit trails, weak breach plans, unclear data retention, and outages during trading hours. He then argues that the rapid pace of model releases is colliding with old enterprise architecture. In his estimate, models and products account for 40% of becoming AI native, while the remaining 60% is less visible work such as entitlements, clean data, integration, enablement, and change management. Agents make weak permission systems more dangerous because they inherit existing foundations.
Enterprise AI buying narrows quickly from many startups to very few contracts
For each internal pain point, Lewis may identify 10 to 15 startups, schedule two or three demos, and run zero or one pilot. About one in four pilots becomes a longer-term contract, which means roughly 5% of demo calls produce a signed agreement. He says this matches published industry benchmarks. The funnel explains why a startup can appear to have strong early interest while still having little chance of becoming a customer. Lewis divides the reasons for failure into efficacy and commercial issues, security, reliability, and legal requirements. His talk focuses on what an enterprise buyer needs to see before moving through each stage.
A useful product must prove its value and its integration early
Lewis says the product has to solve the actual problem, and its pricing has to reflect real value. Buyers want to see working integrations on day one, rather than a promise about what will exist later. They also define the success criteria for a pilot. He describes pitches for products that an internal platform team could rebuild in about six weeks. Sometimes buying still makes sense, but sometimes building is the better choice. He also criticizes pricing based on traffic that never runs through the vendor's infrastructure. One startup wanted Millennium to report its own LLM gateway telemetry so the vendor could add a large margin to that traffic. Lewis says the request did not work.
Pilot timelines are shrinking from months to weeks
Lewis has seen enterprise pilot windows change during his little more than two years at Millennium. Pilots that once lasted around six months moved toward three months, and then toward two weeks. He links the change to the rapid acceleration of the AI market. A shorter pilot leaves less room for a vendor to make basic capabilities appear later or to postpone requested work. It also makes day-one integration, clear success criteria, and concrete answers to customer questions more important. Lewis advises salespeople to listen to what customers ask for instead of repeatedly repitching features the customer has already declined.
Security requires control over data, deployment, permissions, and encryption
Lewis describes zero data retention as a major requirement, with customer-managed encryption keys as an alternative when they do not break the product. Millennium prefers to route traffic through its own gateway, use its own infrastructure, and deploy in its own cloud environment. Permissions should connect to directory groups through SCIM-tied role-based access control, and settings should be configurable through an API. He also wants smaller companies to have at least one real security hire. A product that turns on a feature for everyone, requires read-write access to everything, or sends data to vendor cloud servers without following the requested controls cannot satisfy these requirements.
Enterprise buyers treat missing operational controls as product failures
Lewis wants every administrative setting available through an API, audit logs for configuration changes, controlled rollouts, real service-level agreements, and a reachable support engineer. He describes applications that release updates several times a day and let someone relaunch across thousands of users without tracking versions or changes. A broken SSL certificate can then be difficult to diagnose, and the vendor may have no way to deploy a fix at scale. Documentation can create a similar problem when support pages change without version history or when new risks appear online without appearing in the legal contract. A core API being unavailable for hours during a busy trading day is especially serious for Millennium's production systems.
Legal terms expose hidden data retention and fourth-party risk
Millennium does not want vendors training on its data. It also wants transparency into subprocessors because risk from a fourth party becomes the buyer's risk. Lewis asks for IP indemnification with reasonable liability caps, since the customer does not control the models and should not automatically bear responsibility for infringing output. He describes vendors that claimed zero data retention but later revealed they had retained customer data. He also criticizes features kept permanently in beta because beta terms allow broader data retention. Fourth-party risk hidden on an unlisted website page creates another problem because buyers may not discover the term while reviewing the contract.
The fast release of models collides with slow enterprise architecture
Lewis says a new frontier model arrives on average every 11 days, while an enterprise architecture may be a decade or more old. The gap includes legacy systems, security and privacy problems, and change management. He notes that ChatGPT has existed for 43 months while some companies are still completing ERP migrations that began five years earlier. His estimate is that AI models and products account for 40% of becoming AI native. The remaining 60% is work on data hygiene, clean architecture, integration, enablement, and change management. He describes AI as a flashlight that exposes what already works and what does not. It cannot repair legacy architecture or run organizational change management.
Agents multiply the consequences of weak permissions
Lewis says enterprise entitlements need a new model because existing systems already leave some people over-entitled and others under-entitled. Agents make the problem harder because they need to act quickly and exercise judgment across systems. He argues that agents inherit the foundations they are given, so a process or permission failure can become much larger when an agent is involved. He also says cross-platform integration has moved higher in the stack because AI is limited by what it can reach. Centralized knowledge, including documentation and support articles, can give agents a better substrate. Some companies may need a separate experimentation ecosystem if the gap between their legacy architecture and their target state is too large.
"This means about 5% of all of our demo calls actually end up in a signed contract."03:24
Who should watch
You are building an AI startup and need to understand why enterprise demos turn into pilots, then stop before procurement.
You work on enterprise security, platform engineering, or procurement and want a buyer's concrete requirements for AI vendors.
You are planning an agent rollout on top of old systems and need to examine permissions, integration, documentation, and change management first.
