Checklist: starting an AI project properly
For: Management, business units and IT
Updated: 2026-11
An AI project starts properly with a clear problem and a measurable success criterion, clarified data and permissions, a reasoned model choice, AI Act and data protection classification, a test set of real cases, defined human approvals and a plan for operation.
Many AI pilots end without anyone being able to say whether they succeeded. What is usually missing is not technology but an agreed goal and a way to measure it.
The checklist covers the points that should be settled before the first prototype.
The checklist
- 01
Name the problem
Describe the workflow to be improved and who benefits.
Done when: The problem is described in two sentences and confirmed by a business unit.
- 02
Define a success measure
How you will measure whether the solution helps, such as handling time, accuracy or satisfaction.
Done when: A measurable success criterion with a baseline value is agreed.
- 03
Clarify data and permissions
Which data the solution needs, where it is and who may access it.
Done when: Data sources and access rules are documented.
- 04
Classify for regulation
Check role under the AI Act, possible high-risk classification, transparency duties and data protection basis.
Done when: The classification is recorded in writing, and open questions are named.
- 05
Build a test set
Collect real examples with verified results against which every version is measured.
Done when: A test set with enough real cases exists.
- 06
Define human approval
Decide which steps the AI may perform on its own and where a human decides.
Done when: For each step with external effect, the approval rule is defined.
- 07
Plan operation
Who monitors quality and cost, updates content and intervenes when problems occur.
Done when: Owners for operation and monitoring are named.
Common mistakes
- —The project starts with a tool instead of a problem.
- —There is no baseline value, so the benefit cannot be demonstrated.
- —Permissions are clarified too late, and the prototype shows data not everyone may see.
What this checklist does not cover
- —The checklist does not replace a legal review for potential high-risk applications.
- —Applications in regulated processes face additional sector-specific requirements.
Parent service: AI consulting & integration
Matching offers
AI opportunity assessment
The AI opportunity assessment answers one question: where does AI bring measurable benefit in your company, and where not? We capture workflows with business units, rate use cases by benefit, feasibility, data and risk, and recommend the two or three worth doing first, classified under the AI Act and data protection.
AI chatbot on your own data
An AI chatbot on your own data answers questions from your documents, policies, product information or knowledge articles and cites the source. For customers on the website or staff on the intranet, with a permission concept, hosting in Switzerland or the EU, continuous quality measurement and the transparency notice the AI Act requires.
FAQ
How big should a first AI prototype be?
Small enough to be measured on real cases within a few weeks, and large enough for the result to support a decision.
Do we need an AI policy first?
A short policy makes sense as soon as staff work with AI tools. It does not have to be complete before the first project.
More checklists
Checklist: preparing software makers for the new product liability rules
By December 2026, software makers should inventory their products, define update commitments, introduce a vulnerability process, retain development and test records, review contracts and terms of use, and check that their liability insurance covers software risks.
Checklist: introducing an ISMS to ISO 27001
Introducing an ISO 27001 ISMS follows fixed steps: define the scope, appoint roles, inventory assets, assess risks, select controls in the statement of applicability, introduce policies, train staff, audit internally and have management review the system.
Checklist: being ready for supplier and security questionnaires
Suppliers receiving security questionnaires should be prepared: one responsible person, current core documents on security and data protection, a list of their own providers, evidence for backups and access protection, an answer library and a clear rule on how gaps are handled.