A startup planning its first AI product should start by fixing its role, its intended purpose and its classification screening in writing, before building the marketing, the pricing or the launch plan around the product. It should then plan the evidence it will need for the duties that apply to its role, the support it can use under Article 62, and the external advice it will need for borderline questions. It should record decisions, versions and dates as it goes, because a file built retrospectively is weaker than a file built alongside the product. This guide gives a planning order and a record structure. It does not give a launch checklist that can be copied without adaptation, and it does not state costs, because costs depend on the system, the conformity route and the advisers used.
What should be fixed before building?
Before building, a startup should fix in writing the problem the product solves, the users, the intended purpose in the terms the Act uses, the data the system will use, the decisions or actions it will support, and the role the startup will play. The intended purpose should be written as a statement that can be tested: what the system is for, who it is for, where it will be used, and what it is not for. That statement will be used in instructions, marketing, technical documentation and contracts, and inconsistencies between those documents will create classification and liability problems. The startup should also fix the classification screening questions it will answer: whether the system is an AI system under Article 3, whether Article 5 prohibits the practice, whether Article 6 classifies it as high risk through Annex I or Annex III, and whether Article 50 transparency duties apply. Those questions should be answered with reasons and evidence, not with a single word. A startup that fixes the intended purpose and the screening early can design the product, the data and the oversight around the answers. A startup that leaves them until launch will find that design choices made for other reasons have created regulatory problems that are expensive to undo.
How should a startup choose its first use case?
The first use case should be chosen on the basis of risk as well as market opportunity. A use case that falls in Annex III, that involves vulnerable people, that makes consequential decisions, or that is a safety component of a product will carry heavier duties and a longer evidence build than a use case that does not. That does not mean a startup should avoid high risk uses altogether, but it should choose them knowingly, with the resourcing and the timeline that the duties require. A startup with a small team and limited capital may be better served by a first product whose classification is clear and whose evidence can be built well, with a high risk product following once the team, the file and the customer base are established. The choice should be recorded with the reasons, including the alternatives considered and rejected. The record should not present the choice as a legal determination, but as a planning decision that will be revisited when the product, the law or the guidance changes. A first product that is launched with a clear, well evidenced file will also be easier to explain to customers, investors and authorities than a product whose file was built under pressure after launch.
For the broader regulatory framework, see SMEs, startups and open source overview.
What evidence should be built alongside the product?
Evidence should be built alongside the product, in the same cadence as development. For each version, the startup should record the intended purpose, the data used for development and testing, the performance measures, the limitations and failure modes, the human oversight design, the logging, the risk assessment and the testing performed. For a high risk system, that evidence forms the basis of the technical documentation, the risk management system and the quality management system. For a system that is not high risk, the evidence still supports the transparency duties, the customer explanations and the post market monitoring. The evidence should be stored in a form that can be inspected, with version control, dates and authors. Test results should include failures and the action taken, not only successes. Data should be described in terms of source, representativeness, quality checks and known biases, without disclosing personal data unnecessarily. A startup that builds evidence alongside the product will find that the conformity file is a compilation of existing records. A startup that builds the product first and the evidence later will find that it cannot reconstruct the data, the tests or the decisions, and that the file is weaker for it.
How should a startup use external help?
A startup should use external help for the questions it cannot answer internally, and should record the help it received. External help can include legal advice on classification and role, technical advice on standards and testing, notified body advice on the conformity route, and sandbox guidance from the competent authority. The help should be sought early for borderline questions, not after a decision has been made and communicated to customers. The startup should brief the adviser with the intended purpose, the system description, the data and the screening reasoning, and should record the advice, the date and the action taken. Advice that is sought on incomplete facts, or that is recorded only as a verbal assurance, will be difficult to rely on later. The startup should also be careful with advice from vendors, investors and accelerators that is presented as legal advice but is in fact general information or a sales claim. General information, including this guide, can help a startup to ask the right questions, but it cannot make a legal determination for a specific product. The distinction should be kept clear in the record.
What should the launch record contain?
The launch record should contain the final intended purpose, the final classification screening with reasons, the Article 5 and Article 50 screens, the conformity assessment where required, the declaration and registration where required, the instructions for use, the transparency information, the post market monitoring plan, the incident reporting arrangements, the customer and deployer information, and the version history. It should also contain the decisions taken, the alternatives rejected, the advice received and the open items, with owners and dates. The record should be signed by the person responsible for the launch, and should be kept in a form that can be produced to an authority. A launch record that contains only marketing material and a launch date does not show that the regulatory work was done. A launch record that contains the screening, the evidence and the open items shows that the work was done and that the remaining questions are being managed. Open items should not be hidden. A launch with open items can be legitimate where the items are minor, are owned and are dated, but a launch with a major open item, such as an unresolved prohibition screen, should be paused until the item is resolved.
Continue with who counts as an SME.
What does this planning guide not do?
This guide does not give a startup a business plan, a funding plan or a product specification, and it does not state what a startup must do for a specific product. It does not estimate costs, timelines or headcount, because those depend on the system, the conformity route, the standards and the advisers. It does not replace legal advice, notified body advice or sandbox guidance. A startup with a specific product should use this guide to structure its planning, to ask the right questions and to build its record, and should confirm borderline questions with a competent authority or legal adviser. Planning well does not guarantee a successful product, but planning badly, by leaving the regulatory work until after launch, makes a successful product harder to defend.
Frequently asked questions
Should a startup avoid high risk products for its first launch?
Not necessarily, but the choice should be knowing. A high risk use case carries heavier duties and a longer evidence build. A startup should choose its first use case with risk, resourcing and timeline in view, record the reasons, and build the evidence alongside the product. A first product with a clear classification and a well evidenced file is easier to defend than a high risk product launched without a file.
Can a startup build the compliance file after launch?
It can compile a file after launch, but the file will be weaker where data, tests and decisions cannot be reconstructed. Evidence should be built alongside development, with versions, dates and failures recorded. A retrospective file that presents estimates as records should not be used.
What external help should a startup seek first?
Help for borderline classification and role questions, for the conformity route and for standards and testing, sought early and recorded with the facts briefed and the advice received. General information, including this guide, cannot make a legal determination for a specific product, and vendor or investor material should not be treated as legal advice.
What makes a launch record useful?
A launch record that contains the final intended purpose, the screening with reasons, the conformity and registration position, the instructions and transparency information, the monitoring and incident arrangements, the decisions and advice, and the open items with owners and dates. It should be signed, dated and producible to an authority, with major open items resolved before launch.
Continue through this AI Act cluster
This article is an informational overview, not a legal determination. Check the current legal text and official implementation guidance for your system and role.
Consolidated Regulation (EU) 2024/1689 ↗AI Act Service Desk timeline ↗