The AI Act made product boundaries a business decision

The EU AI Act made product purpose, customer use and supplier responsibilities central to software procurement, development and contracts.

The European Commission's Berlaymont headquarters in Brussels, with a blue European flag banner at the centre of its facade.
European Commission's Berlaymont headquarters, Brussels.EmDee (opens in a new tab) · CC BY-SA 4.0 (opens in a new tab)

On 1 August 2024, the European Union's AI Act entered into force. For a company selling software to European customers, the commercial consequences began before most of the obligations applied. A prospective buyer could now ask where a product belonged within an agreed legal framework, what evidence its supplier retained and who would be responsible when the system changed. These questions reached product development, contracts and the sales process together.

The adopted regulation provided a phased timetable, with the first prohibitions and AI literacy provisions due in February 2025 and most rules scheduled for August 2026. Businesses faced two immediate tasks: deciding which provisions covered their products and planning the work required before the relevant deadlines.

A model name could not establish the risk category

The Commission's announcement grouped systems by the risks associated with their uses. Recruitment and certain credit decisions were among the sensitive applications. A document search tool, a system that ranked job applicants and a model used within medical equipment could share technical components while presenting different obligations. The original Article 6 and its annexes set out the classification tests, including conditions and exceptions. Treating every use of machine learning as high risk would have obscured those distinctions.

For a software team, the practical starting point was its intended purpose. Article 3 tied that purpose to the context described in instructions, technical documents and sales materials. A promise added during a sales call could therefore deserve the same scrutiny as a change in functionality. A business offering administrative assistance needed to understand whether customers would also use its outputs to make consequential decisions about people.

Responsibility followed the position in the supply chain

The regulation distinguished the provider placing a system on the market under its name from the organisation deploying it. It also addressed general purpose models, which could become components within many different applications. Buying access to a model did not resolve all the questions surrounding the finished product. A supplier still needed to understand its role, the system it had assembled and the information its customer would need.

Hackathon participants lean over crowded tables of laptops in a blue-lit hall.
Participants at the Junction hackathon, 2015.Vmuru (opens in a new tab) · CC BY-SA 4.0 (opens in a new tab)
Questions for an enterprise AI purchase in 2024

Scroll to view all columns

ComparisonProduct questionEvidence to examine
PurposeWhich decision or task will the system support?Documented use, exclusions and customer instructions.
ResponsibilityWho supplies the system and who operates it?Named roles, contracts and upstream dependencies.
ControlHow can a person review or stop a consequential action?Permissions, review procedures and tested intervention.

Commercial diligence questions informed by the original AI Act. The applicable legal duties depended on the system and its use.

This was especially relevant to enterprise products connecting an external model to customer records, retrieval software and approval processes. Model performance alone said little about data access, the reliability of retrieved material or what happened when an employee accepted an incorrect answer. An architecture review could identify these responsibilities. Contracts then needed to reflect what each party could actually observe, control and support, including the consequences of replacing an upstream model.

The transition period created engineering work

For systems classified as high risk, the original framework set requirements covering risk management, data governance, technical documentation, logging, human oversight, accuracy and cybersecurity. The immediate investment decision was how much of that work belonged in a reusable product foundation. Records assembled only at the end of a procurement exercise could be expensive to reconstruct, particularly if earlier model versions, test data or operating assumptions had disappeared.

Illustration of server racks connected to liquid cooling manifolds in a data centre aisle.
Liquid cooling hardware in a data center. Illustration.

Some implementation details were still being developed. The AI Office had just opened its consultation on a general purpose AI Code of Practice, covering transparency, copyright and systemic risk. Businesses could see the direction of the requirements, but detailed questions remained open. Budgets and contracts needed room for that uncertainty, especially where a young company depended on information from a much larger model supplier.

What an investor could reasonably infer

The Act gave investors a more concrete set of questions about enterprise AI businesses. Was the target use sufficiently defined to assess its obligations? Could the company produce evidence without extensive manual reconstruction? Did its planned price cover support, monitoring and the work required to enter a regulated customer's environment? These questions affected the economics of adoption, even where the relevant legal deadline remained some distance away.

The regulation could create demand for documentation, testing and governance software, although customers might not buy a separate tool for each task. Existing security, quality and procurement systems already held much of the necessary information. The stronger opportunity lay in reducing repeated work across those systems. A prepared product team understood its intended use, its dependencies and the evidence needed to explain both.

Investment implications

  • An AI system's intended purpose and use context determined more than the choice of model.
  • Providers, deployers and general purpose model suppliers occupied different positions in the legal framework.
  • Good records could make procurement more manageable, but compliance work did not establish customer demand or product quality.

Sources

  1. Regulation (EU) 2024/1689: original AI Act, particularly Articles 3, 6, 9–15 and 113 (opens in a new tab)

    Official Journal of the European Union

  2. European Artificial Intelligence Act comes into force (opens in a new tab)

    European Commission

  3. AI Act: Have Your Say on Trustworthy General-Purpose AI (opens in a new tab)

    European Commission

CIR Ventures Journal

Published

Browse the journal