How to start an AI project in a company: a practical first plan

How to start an AI project in a company: pick one task that costs real time or money, gather a sample of the data it depends on, define what “good enough” means before anyone builds, then run a small, time-boxed pilot with the people who do the task today. Only scale what the pilot proves, and check data protection and the EU AI Act from the first week, not the last.

Last updated: 21 October 2026.

This guide sets out a first AI project step by step: choosing the use case, checking the data, deciding whether to buy, configure or build, running a pilot, measuring it, handling the rules that apply in Europe and taking a successful pilot into daily use. It is written for founders, operations leads and managers who are being asked to “do something with AI” and want a plan that ends with a result rather than a demo.

At Odduel, a creative and technology agency in Barcelona and São Paulo, our AI development service designs and builds AI features, assistants and automations for companies, and we use AI in our own work: repetitive steps such as first drafts and data preparation are automated, and people review what goes out. The plan below is the one we follow with clients, and it applies whoever builds your project.

In short: start with a task, not a technology. Choose one process where the cost of today’s work is clear and mistakes are recoverable, look at the real data, agree a measurable success test and a human check, and pilot it for a few weeks with the people who own the task. Buy or configure an existing tool where one fits; build only where your process or data is the advantage. Keep a record of what data goes where, tell people when they are dealing with an AI system and train the team that will use it.

Step 1: Choose the first use case

The best first AI project is narrow, frequent and measurable. It replaces or speeds up a task people already do, uses data you already have and produces results someone can check.

• Frequent: the task happens many times a week, so small gains add up.
• Costly today: you can say roughly how many hours or how much delay it causes.
• Checkable: a person can tell whether the output is right.
• Recoverable: a mistake can be caught and fixed before it reaches a customer, or matters little if it does.
• Owned: the people who do the task today want it improved.

Typical first projects include sorting and answering routine enquiries, extracting data from documents, drafting first versions of standard texts, summarising long material for review, tagging and searching internal knowledge, and checking content against rules. Projects that start with “an AI strategy for the whole company” or “a chatbot that knows everything” usually stall.

The table compares common starting points on how quickly they show value and how much care they need.

First use case	Typical value	Data needed	Main risk	Human check
Sorting and drafting replies to routine enquiries	Faster response, less manual triage	Past enquiries and answers	Wrong or overconfident replies	A person approves before sending, at first
Extracting data from documents	Less retyping, fewer errors	Sample documents with correct values	Misread fields	Spot checks and exceptions queue
Drafting standard texts	Time saved on first drafts	Approved examples, style rules	Inaccurate facts, off-brand tone	Editor reviews every text
Searching internal knowledge	Faster answers for staff	Up-to-date documents with owners	Out-of-date or confidential answers	Sources shown with every answer
Checking content against rules	Consistent reviews	The rules and labelled examples	Missed cases	Reviewer handles flagged items

Step 2: Look at the data before the model

An AI project is only as good as the data it works with. Before choosing a tool, collect a realistic sample: a few hundred enquiries, a batch of documents, the knowledge base as it really is.

• Is it available? Where it lives, who owns it and whether it can be exported.
• Is it representative? It should include the awkward cases, not only the clean ones.
• Is it current? Out-of-date documents produce out-of-date answers.
• Is it personal? If it includes personal data, the GDPR applies to how it is processed, where it is sent and how long it is kept.
• Is it confidential? Decide what may be sent to an external AI service and under which contract terms.

Often the first useful result of an AI project is a cleaner, better-organised data source, which helps the business even before any model is used.

Step 3: Define success before anyone builds

Write down, before the pilot, how you will know it worked. Without a test agreed in advance, every demo looks promising and no decision follows.

• A baseline: how long the task takes today, how often it goes wrong, what it costs.
• A target: for example, the share of enquiries correctly sorted, the time saved per document or the share of drafts accepted with light edits.
• A test set: real examples, with the right answers, kept aside to measure the system fairly.
• A quality floor: the kinds of mistake that are not acceptable at all, such as inventing a price or a legal statement.
• A human check: who reviews outputs, how and for how long.

Step 4: Buy, configure or build

Many first projects do not need custom development. The choice depends on how standard the task is and how much your own process or data is the point.

• Buy a ready-made tool when the task is common and the tool fits your data, languages and security needs.
• Configure a general AI service or platform with your documents, prompts, rules and integrations when the task is standard but the content is yours.
• Build a custom feature or agent when the task is central to how you compete, when it must work inside your own product or systems, or when no tool meets your requirements.

If you are deciding who should build it, our comparison of an AI development company and a freelancer covers the trade-offs, and our guide to agentic AI and generative AI explains which kind of system suits which task.

Step 5: Run a time-boxed pilot

A pilot is a real test with real users on a small scale, with a fixed end date and a decision at the end. A few weeks is usually enough to learn whether a narrow use case works.

1. Start with the test set. Measure the system against the examples kept aside before anyone uses it.
2. Put it in front of the people who do the task, in the tools they already use, with a human approving every output at first.
3. Log everything: inputs, outputs, corrections and time spent.
4. Review weekly with the task owner: what it gets right, what it gets wrong and what to change.
5. Decide at the end: scale, adjust and test again, or stop. Stopping a pilot that does not meet its test is a good result; it saves the cost of scaling something that does not work.

Step 6: Handle the rules from the start

In Europe, two sets of rules matter for most first projects.

• Data protection. Under the GDPR you need a lawful basis for processing personal data, a record of what goes to which service, data processing agreements with providers, and in some cases a data protection impact assessment. Keep personal data out of the pilot unless it is needed.
• The EU AI Act. The AI Act entered into force in August 2024 and its obligations apply in stages. It bans certain practices, sets strict requirements for systems classed as high-risk, such as some uses in hiring or credit, and imposes transparency duties, for example telling people when they are interacting with an AI system. Since February 2025 it also expects companies using AI to make sure their staff have a sufficient level of AI literacy.

Most first projects, such as drafting, search or document extraction, are not high-risk, but check the classification early with legal advice, especially for anything that affects people’s access to jobs, credit or services. This is general information, not legal advice.

Step 7: Take a successful pilot into daily use

A pilot that meets its test still needs work before it becomes part of the business.

• Integration with the systems people use every day, so the tool is not a separate window.
• Monitoring of quality over time, because data and requests change.
• Clear ownership: who maintains the prompts, rules, data sources and integrations.
• Training and guidelines for the team, including what the system must not be used for.
• A route for mistakes, so users can flag wrong outputs and someone fixes the cause.
• Cost tracking, because usage-based AI services cost more as use grows.

Then choose the next use case, using what the first one taught you about your data and your team. Our article on AI in web design and development shows how this works when AI features sit inside a website or app.

What are the common mistakes when you start an AI project?

• Starting with the technology. Choosing a model or tool before knowing which task it should improve.
• Too broad a scope. Trying to automate a whole department at once.
• No baseline. Not measuring the task before the pilot, so the gain cannot be shown.
• Clean demo data. Testing only on easy examples and failing on real ones.
• No human check. Letting outputs reach customers before quality is proven.
• Ignoring the people who do the task. Building without them and then finding the tool does not fit how they work.
• Leaving compliance to the end. Discovering late that data cannot be sent where the design assumed.

Questions people ask

Start with one task, real data and a test agreed in advance, and let a short pilot decide what comes next. See how our AI development service plans and builds AI projects, or tell us about your project and we will help you choose the first use case.