Brian Lewis

Brian Lewis works on enterprise AI adoption and vendor evaluation, connecting product value with the practical requirements of operating software inside a large organization. At AI Engineer World’s Fair 2026, he was an AI Product Lead at Millennium. His buyer’s perspective centers on the distance between a convincing demonstration and a usable product: working integrations, appropriate permissions, controlled releases and enforceable data commitments.

From economics and analytics to practical software

Lewis’s background spans economics, data science and product work. He earned a bachelor’s degree in economics and graduated from Northwestern University’s Master of Science in Analytics program in 2021. Earlier in his career, he worked as a data scientist at Cornerstone Research, applying computational methods to economic and legal-policy questions.

• Merger-comment analysis: In 2022, he co-authored an analysis of public comments on merger enforcement with Andrew Sfekas and Bryan Pine. The authors combined automated text analysis with manual review to examine concerns about health care, technology companies, wages and competition, including the influence of organized submission campaigns. Their analysis also explained a limitation of topic modeling: concerns shared across otherwise distinct groups could fail to emerge as a separate topic. Explicit searches for wage-related language recovered a substantial theme that the automated grouping had missed. The work used computational scale while retaining human interpretation of what the categories overlooked.
• Excel workbook conversion: Lewis’s public software includes xlsb2xlsx, a Python utility released on PyPI in 2022 that converts binary Excel workbooks into the more widely supported .xlsx format. It supports directory-wide and recursive conversion through a wrapper around the proprietary Aspose.Cells library. Its documentation identifies that dependency and the limitations of its evaluation version, making clear what the utility provides and what it relies on.

What enterprise AI vendors must deliver

By his 2026 conference appearance, Lewis had spent a little over two years at Millennium. He described product responsibilities that began with identifying internal problems, deciding whether to build or buy a solution, and evaluating startups that might meet those needs. His enterprise AI talk explained the obstacles he encountered in that process. He spoke as an individual; his arguments and examples represent his personal views rather than Millennium’s positions.

• Buyer-defined success: For Lewis, product evaluation starts with buyer-defined success criteria. A vendor must solve the customer’s problem, demonstrate integrations from the beginning and price the product in relation to the value delivered. He described rejecting a proposal to charge a large markup based on language-model traffic passing through the buyer’s own gateway, even though the traffic did not run through the vendor’s infrastructure. He also noted that some proposed products could be rebuilt internally in roughly six weeks, while acknowledging that buying could still be preferable. Build-versus-buy judgment requires examining the whole purchase rather than assuming that either technical novelty or internal reproducibility settles it. As pilot periods shortened from months toward weeks, promises of future integrations became less useful than functionality available for evaluation.
• Access and data protection: His security requirements connect access and data protection to product behavior. Lewis favors zero data retention and, when retention cannot be avoided, customer-managed encryption keys that preserve the application’s functionality. He wants vendors to support the customer’s infrastructure and language-model gateway, with role-based access tied to existing identity groups and configurable through an API. A one-click integration that requires unrestricted read and write permissions can be unsuitable for an enterprise even when its demonstration looks compelling. New features also need controlled activation: different groups may require different access, and a release should not automatically enable every feature for everyone. Lewis describes himself as a frontline participant in these vendor conversations, rather than a security specialist.
• Operational control is equally important to his definition of enterprise readiness. Administrators need API-accessible settings, audit logs for configuration changes and control over software rollouts, backed by meaningful service-level commitments and reachable support engineers. He described rapidly updated applications in which thousands of users could independently move to different versions. When a release broke something, administrators struggled to reconstruct the problem or deploy consistently at scale. Documentation needs version history for similar reasons: revised support pages can introduce terms or risks without giving customers a way to compare the previous wording. These controls make it possible to understand and manage a product after its initial pilot.
• Enforceable data commitments: Lewis also connects contractual assurances to actual data handling. A zero-retention promise fails when a vendor later refers to customer information it should not have kept. Retention clauses attached to beta features can weaken broader commitments, while undisclosed subprocessors introduce risks the buyer cannot assess from the contract alone. He calls for transparency about those parties, commitments against training on customer data, and intellectual-property indemnification with reasonable liability caps. His concern is whether the promised protections hold across features, dependencies and implementation.

The organizational foundations of AI adoption

His argument for enterprise buyers begins with the hypothesis that organizations are already leaving substantial value unused at existing levels of model intelligence. He informally assigns the larger share of adoption work to data hygiene, architecture, integration, enablement and change management; he explicitly presents that allocation as a hypothesis rather than a measured statistic. His image of AI as a flashlight captures the mechanism: it exposes the systems and practices already helping or hindering work, accelerating effective processes while revealing weaknesses that a new model cannot repair on its own.

Agents make those foundations more consequential. Existing entitlement systems may grant people too much or too little access; agents inherit those permissions and can exercise them quickly across systems. Lewis therefore urges buyers to repair access controls, improve cross-platform integration and make organizational knowledge readily consumable. Documentation and support knowledge should be centralized so agents can reach the information they need. He also discusses a possible feedback loop in which AI helps maintain that knowledge, and a separate environment for experimentation when legacy architecture is too far from what an AI workflow requires. These are directions he advocates or describes exploring, rather than claims of completed internal systems.