AI Implementation: How to Implement AI in Business, Step by Step (From Someone Who Builds It)

Here's how to implement AI in business, in the order I do it on every build:

1. Pick one process that repeats often, follows rules most of the time, and costs something when it's slow.
2. Map it by hand before any code: inputs, decisions, exceptions, who checks the result. (How I split each step into rules, AI or a person: AI process automation.)
3. Check the data the AI will read. Thin or wrong content gives you a thin or wrong system.
4. Decide: buy, configure or build. Buy when a tool already fits. Build when nothing on the shelf handles your edge case.
5. Build the smallest version that does real work, and test it on real inputs, not demo inputs.
6. Put a human at the edges: decide which cases go to a person, and tell customers when they're talking to AI.
7. Ship it where people already work, on the website or inside the tool your team opens every morning.
8. Measure it against the numbers you wrote down in step 2, then keep, fix or switch it off.

I'm Panagiotis Karampetsos. I build AI systems for small and mid-sized businesses from Heraklion, Crete: AI chatbots live on three hotel websites, a system that fills a shipping company's vessel equipment templates from its manuals and registers, a patent screening agent for a pharma R&D team, and os.liberators.ai, the agent platform I built and run them on. Below is how I do that work, and where it has gone wrong for me.

What AI implementation means in practice

AI implementation is the work of getting an AI model to do a specific job inside a business, reliably, with real data, in front of real people. The model is the easy part. You can call GPT, Claude or Gemini through an API in an afternoon.

Everything around the model is the hard part:

• Where the input comes from. An email, a scanned document, a chat message, a form.
• What the model reads to answer. Your own documents, your website, your database. This is called grounding, and most of the quality lives here.
• What happens to the output. Does it go to a customer, into a spreadsheet, into your booking engine, to a person for approval?
• What happens when it's wrong. And it will be wrong sometimes.

So when someone asks me "how do we implement AI?", I translate it to a smaller question: which job do you want off your team's plate, and what does a correct result look like?

Why most AI implementation projects stall

The numbers aren't flattering. Read them before you spend money.

MIT's NANDA initiative published The GenAI Divide: State of AI in Business 2025, based on 150 interviews with leaders, a survey of 350 employees and an analysis of 300 public AI deployments. As Fortune reported on 18 August 2025, about 95% of generative AI pilots delivered little to no measurable impact on profit and loss. The report puts the cause on integration, not on model quality.

IBM's CEO study, released 6 May 2025 and based on 2,000 CEOs, found that only 25% of AI initiatives had delivered the expected ROI over the previous few years, and only 16% had scaled enterprise wide.

Those are big companies. My read after building for small ones: the failures come from the same place. The project starts with "we should use AI" instead of "this job takes too long". Nobody writes down what the job costs today, so nobody can say later whether the AI helped. And the AI gets built next to the process instead of inside it.

Every step of AI implementation below exists to prevent one of those.

How to implement AI in business: 8 steps

Each step below is something I do on real builds, with the project it came from.

Step 1: Pick one process, not an "AI strategy"

The first thing I ask a business owner isn't about AI. It's: "What do you or your people do every week that you'd hate to do by hand for another year?"

A good first process has three traits:

Trait	Why it matters	Example from my builds
It repeats often	The savings multiply with volume	Hotel guests asking the same questions about check-in, parking and transfers
It follows rules most of the time	The AI can be checked against those rules	Matching an invoice to its delivery note on supplier, store, date and quantities
Being slow or wrong costs something	That cost is what pays for the build	Staff matching a vessel's equipment list, item by item, against its manuals and registers

What makes a bad first process: something that happens twice a year, something where every case is a judgement call, or something nobody currently measures.

Don't start with the most impressive idea. Start with the most boring one that costs you hours. If you want a list to pick from, I wrote up AI automation examples from systems I've built, grouped by the job each one does.

Step 2: Map the process by hand before writing any code

Before I build anything, I sit with the person who does the job and we analyse the work together. Then I write down the process as it actually runs, not how the manual says it runs.

I do this in working sessions with the owner and the people who do the work. A form filled in once at the start doesn't tell me enough. The same sessions are where I get access to the systems and the context I need to connect them properly.

For a Greek supermarket chain with 175 stores and a heavy monthly load of invoices, delivery notes and credit notes, the process looked simple on paper: take the invoice, find its delivery note, compare, file. Mapping the real documents showed the blocker. The date that matters is the receipt date, and it lives in the warehouse's receipt stamp on each delivery note: in Greek, stamped or written by hand, often tilted, often with a signature across it. Standard OCR can't read it reliably. Without that date, automatic matching falls apart.

The field that decided the design: the receipt date inside the warehouse's stamp, with the month in Greek letters and the whole stamp at an angle. Standard OCR misses it.

That one detail decided the whole design: printed text goes through OCR, the receipt-stamp dates go through a vision model, and a matching step pairs documents and flags anything that doesn't agree for a person to review. If I'd skipped the mapping and started coding, I'd have built a pipeline that failed on the one field that mattered.

What to write down in this step:

• The inputs, in their real, messy form. Collect a few dozen real examples.
• The decisions, and which of them follow a rule.
• The exceptions that break the rule, and how often they appear.
• Who checks the result today, and how.
• What it costs today: hours per week, delays, errors. You'll need this in Step 8, and it's the base of any honest AI ROI estimate.

Step 3: Check the data the AI will read

Most AI systems I build are grounded: the model answers from your content, not from what it learned on the internet. That's what makes it useful, and it's also where most quality problems come from.

With hotel chatbots this shows up fast. A hotel chatbot knows nothing about the hotel except what you give it: the website, room descriptions, policies, FAQs, local tips. If the cancellation policy on the site is out of date, the bot quotes the old policy, faster and in more languages than any receptionist would. I cover this in detail in my hotel chatbot guide.

For the shipping company, the data problem was different. The information existed, spread across each vessel's manuals and equipment registers. The work arrives as the vessel's Excel template: a list of machinery and equipment items, each of which has to be matched to those files. So the parsing had to keep the link to the source down to the file and row. Every filled cell points to where it came from, and every candidate the system rejected is listed with the reason, like a name mismatch. A person can check a match in seconds and see what was ruled out. Without that, nobody would trust a filled-in template.

The upload step: drop in a vessel's machinery Excel, and each row gets matched against 3,301 documents across 81 vessels.

Questions to answer before you move on:

• Where does the information the AI needs live today?
• Is it current? Who keeps it current?
• Can the system cite where an answer came from?
• Is any of it personal data? If yes, where can it be processed?

Step 4: Decide whether to buy, configure or build

This is where I'll say something a builder isn't supposed to say: often you shouldn't build.

The MIT NANDA report found that companies buying specialised AI tools from vendors succeeded about 67% of the time, while internal builds succeeded only about a third as often (as reported by Fortune, 18 August 2025). I take that seriously. If a tool already does your job, buy it.

Option	When it fits	Watch out for
Buy a ready SaaS tool	Your process is standard and the tool covers it end to end	Per-seat or per-conversation pricing that grows with you, and data you can't take with you
Configure a platform	The job is common (a website chatbot, a document Q&A) but needs your data and your rules	The platform's limits on integrations and handoff
Build a custom system	Nothing on the market handles your edge case, or the job sits across several of your own tools	You need someone to maintain it after launch

Most of my client work sits in the middle row. The hotel chatbots on Aroma Suites, Casa di Terra Villa and Amoopi Nymfes are configured agents on os.liberators.ai, the platform I built: each gets its own knowledge base from the hotel's site and documents, its own instructions and its own handoff rules. I build from scratch when there's no other way, like reading the Greek receipt dates off stamped delivery notes, or a patent screening agent that has to search European, US and other patent databases at the molecule level and flag each patent's legal status and expiry.

Configure, not build: a hotel's agent is a knowledge base, a set of instructions and handoff rules on a platform that already exists.

Step 5: Build the smallest version that does real work

The first version should do one job end to end on real inputs. Not a demo on five clean examples.

For a chatbot that means: the real website content loaded, the ten questions guests really ask, tested in the languages they write in. For a document pipeline it means: a batch of real scanned documents, including the ugly ones.

Then I run the real examples from Step 2 through it and sort the results into three piles:

1. Correct. Good.
2. Wrong, and the system could have known. Fix the data or the instructions.
3. Wrong, and it needs a person. That's a handoff rule, not a bug.

Pile 3 doesn't mean the project failed. Every AI system I've shipped has one. Most of the work is deciding where it starts.

Step 6: Put a human at the edges

Every system I ship has a clear path to a person. The hotel chatbots hand over complaints, refunds and complex booking changes. The invoice matching flags mismatches for review instead of guessing. The patent agent cites every result back to its source filing so a person can check it.

There's also a legal side in Europe. Article 50 of the EU AI Act, which applies from 2 August 2026, requires that people are told when they're interacting with an AI system, unless that's obvious from the context. So label the bot.

The handoff from the staff side. Complaints, refunds and complex booking changes land here instead of getting a guessed answer.

My rule: the AI does the repetitive part, a person owns the judgement calls, and the customer always knows which one they're talking to.

Step 7: Ship it where people already work

An AI tool in a separate tab gets used for a week, then forgotten. Put it inside the inbox or the website and people use it without thinking about it.

This is also where the unglamorous engineering shows up. On Aroma Suites, the chat widget was one of four third-party scripts loading right after the page, and together they made the mobile PageSpeed score jump around from one run to the next. The fix was loading them only after the visitor's first interaction, or after a short delay. After that the score stayed in the nineties over four runs, and blocking time stayed low. A chatbot that slows down the hotel's website costs more direct bookings than it wins.

The chat lives on the hotel's own homepage, not in a separate app. The answer comes from the hotel's own policies, and availability sits right under it.

The same thinking applies inside a company. For a marketing agency I built a multi-agent platform where a central orchestrator routes each request to one of five specialist agents, and those agents read and write Google Workspace files directly, because that's where the agency's work already lived.

Shipping also means teaching the people who'll use it, and I do that in a set order. First, how to set things up and keep them organised. Then how AI fits into the work they do every day. More advanced use comes last.

Step 8: Measure it, then keep, fix or switch it off

Go back to the numbers from Step 2. Compare them with what the system does now: hours spent per week, response time, error rate, what still needs a person.

I don't hand the system over and disappear. I stay in touch with the team until it's stable and doing the job properly, and these numbers tell us both when that is.

Then make one of three calls:

• It pays for itself? Keep it, and look at the next process.
• It helps but costs too much, or makes too many mistakes? Fix the data, the instructions or the handoff.
• It doesn't help? Switch it off. That's a result too, and it's cheaper to learn at the pilot stage.

I wrote a separate guide on how to estimate AI ROI before you build, with the worksheet I use.

How to use AI in business: where to start by team

If you're still at "how do I use AI in my business at all", this is where I'd look first. Each row is a job I've built or scoped.

Team	First job to hand to AI	What the AI does
Front desk, sales	Answering repeat questions on the website	A chatbot grounded on your own content, with handoff to a person
Sales	First reply and lead qualification	Asks the qualifying questions and routes the lead
Accounts	Matching invoices, delivery notes and payments	Reads documents, compares fields, flags mismatches
Operations	Filling templates and lists from manuals and records	Matches each item to its source file and row, and lists what it rejected and why
R&D, legal	Screening large external databases	Searches, classifies and summarises with sources
Marketing	Routine content and reporting work	Specialist agents working inside your existing tools

For small teams specifically, I wrote AI automation for small business: where it pays and where it doesn't.

What AI implementation costs a small business

Two parts: building it, and running it.

Building depends on which row of the buy/configure/build table you're in. A configured chatbot on an existing platform is a much smaller project than a custom document pipeline. I price after I've mapped the process in Step 2, because that's when I know what the build involves.

Running is mostly model usage, and it's cheaper than most people expect. At Anthropic's published API prices (source: Anthropic pricing, checked 2 October 2026), Claude Haiku 4.5 costs $1 per million input tokens and $5 per million output tokens, and Claude Sonnet 5 costs $2 and $10. A long customer conversation is a few thousand tokens. For most small-business jobs, the model bill is small next to the build and the time someone spends maintaining the data.

Mistakes I see when businesses implement AI

Starting with the tool. "We bought Copilot, now what?" Start with the job.

No baseline. If you don't know how long the job takes now, you'll never know whether AI helped.

Letting it guess. A system that can't find the answer should say so and hand over, not make something up.

Ignoring the website or tool it sits in. Slow pages, broken layouts on mobile and security headers that block the widget all count as part of the build.

Automating a broken process. If the process is a mess by hand, AI makes the mess faster.

No owner after launch. Content changes, prices change, policies change. Someone has to keep the data current.

FAQ

Where to start

Good AI implementation starts small. Pick one process. Write down what it costs you today. Then talk to someone who builds these systems, not someone who sells a licence. If you're comparing people, here's how to hire an AI developer and what to ask them.

That's what I do as an AI automation consultant: I map the process with you and your team, tell you whether to buy, configure or build, and build it if building makes sense. You can see the systems I've built on my portfolio, or send me the process that's eating your time and I'll tell you what I'd do first.