Cybersecurity briefing
/
AI Companies Need More Than a Product Demo to Win Enterprise Trust
Altus Group's ISO/IEC 42001 certification shows why AI vendors need governance evidence, not just demos, and how security programs keep that record current.
/
AUTHOR
Jeff Dyer
/
SHARE THIS ARTICLE
Overview
An AI company can demonstrate a compelling product long before it can demonstrate the organization behind it. Altus Group’s October 5 announcement that it achieved ISO/IEC 42001 certification offers a concrete example of a technology provider putting its AI management practices alongside its product capabilities. For founders, incoming CISOs and enterprise buyers, the distinction matters: a successful demonstration leaves questions about responsibility, risk and oversight that have to be answered before the technology becomes part of a business.
The organization behind the AI product
In its certification announcement, Altus links the development of its ARGUS Intelligence Platform and AI agents with governance across its products, services and operations. The commercial real estate intelligence provider also says the AI management certification complements its existing ISO/IEC 27001 certification. Altus is an established company, not a startup. Its announcement nevertheless illustrates a challenge younger AI companies must address as they pursue enterprise customers.
The lesson is not that every startup needs a certificate before selling software. It is that technical capability and organizational accountability answer different buyer questions. A demonstration can show how a system performs a task. It cannot, by itself, establish who approves changes to the system, how its risks are assessed or what happens when its behavior falls outside the intended use.
Consider an AI application intended to assist financial analysts. A model update could alter the assumptions behind its output while leaving the user interface unchanged. A new data source could introduce restrictions that were absent from the original implementation. Those are hypothetical examples, but they explain why a buyer’s assessment needs to reach beyond the model’s apparent accuracy. Someone has to own the decisions, assess their consequences and retain the evidence.
A management system has to survive the next release
According to ISO’s description of ISO/IEC 42001, the standard specifies requirements for establishing, implementing, maintaining and continually improving an AI management system. It applies to organizations providing or using AI products and services. That emphasis on an ongoing management system is important. Governance cannot be completed once at launch if the product, its suppliers and its operating context continue to change.
For a company preparing to sell into an enterprise, the practical work begins with defining the scope of its AI offering and the responsibilities around it. Which systems and services are included? Which decisions belong to engineering, security, legal or the business? What evidence supports the risk assessment, and what changes trigger another review? The answers should be consistent with the way the company actually builds and operates the product.
Certification also has to be interpreted within its scope. A management-system certificate should not be treated as a guarantee that every model output is correct or every deployment is safe. Enterprise buyers still need to assess their own use case, data, access permissions and operational consequences. Altus’s announcement is evidence of the company’s stated certification achievement, not proof of a particular customer outcome or shorter sales cycle.
Customer assurances need an operational record
The work becomes harder when customer-facing assurances and internal records diverge. A questionnaire may describe a review process that exists in a policy but has no assigned owner. A risk register may identify a concern without connecting it to a project. A control may be marked implemented even though its supporting evidence is stale. In each case, the organization has information, but it lacks a reliable account of what is operating today.
This is a security program orchestration problem. The assessment, control, evidence, finding and corrective work need to remain connected. A reviewer should be able to trace an assurance back to its basis, identify an unresolved gap and see who is accountable for closing it. That relationship is useful to a prospective buyer, but it is equally useful to a new CISO trying to distinguish inherited practices from inherited assumptions.
For a CISO, those connections extend beyond the compliance team. A supplier assessment can change the risk attached to a control. An acquisition can introduce findings that remain open after the transaction closes. Keeping each in a separate system leaves leadership to reconstruct the relationships whenever a customer, auditor or board member asks how the business is managing its exposure.
Pylon’s platform brings those responsibilities into a shared record across Command, Scout and Anvil. Command manages the security program, including assessments, controls, findings and improvement work. Scout adds third-party assessments and monitoring; Anvil carries technology and security diligence into acquisition integration planning. Controls, vendors, findings and evidence retain their context across the products, giving the CISO a connected view of program commitments, supplier risk and inherited obligations. Built by a practicing CISO and CIO, the platform reflects the responsibility to manage those issues together. Its AI analyst drafts assessment and planning work for human review; accountable leaders determine whether the evidence supports the conclusions.
The distinction between evidence and inference is particularly important when AI assists an assessment. An access-control check can show a configuration at a particular time. It does not necessarily prove that an access review happened, that the reviewer had the right scope or that exceptions were resolved. The assessment needs to preserve those separate questions rather than allow a fluent summary to turn partial evidence into a confident assertion.
Growth changes the governance workload
A startup can initially manage many decisions through a small leadership team. Growth introduces more owners, customer requirements and operating environments. An acquisition or expansion into another subsidiary adds another complication: a consolidated view can obscure differences in what each entity has assessed and implemented. Program reporting needs to make those differences visible while giving leadership a coherent view of the organization.
A practical starting point is one customer-facing AI service. Identify its accountable owner, relevant suppliers, principal risks and the evidence supporting its controls. Link open gaps to specific work and define the changes that require reassessment. Test whether someone outside the original implementation team can follow the record. If the explanation depends on one person’s memory, the program will struggle to survive a leadership transition or a larger customer review.
Altus’s announcement brings that organizational work into view alongside AI product development. For emerging technology companies, the useful response is to build a program that can explain its decisions and maintain its evidence as the product evolves. The demonstration earns attention. A defensible account of how the company governs the product gives buyers a stronger basis for deciding whether to rely on it.
/
BLOG
