Seelight

AI for companies: where to start without burning budget

· 9 min read

How to pick the first processes where AI really saves hours, what to measure before the pilot, and which mistakes burn the budget.

AI in a company is not «putting a chat on the website»

Every week we see companies launch an AI project because «everyone is doing it», burn five thousand dollars on a pilot that changes nothing, and conclude AI was not for their business. The problem was not AI: it was the starting point. Here is the script for starting well.

Step 1: identify the three processes that actually hurt

Before thinking about models or tools, answer this: which repetitive process eats hours from someone on my team every week? Good candidates meet four conditions:

  • It is repetitive: the same pattern every day.
  • Errors have moderate consequences, not critical ones.
  • It consumes at least five hours a week of someone's time.
  • The input is text or structured data, not intuition.

Examples that almost always qualify:

  • Answering frequent questions on chat, WhatsApp or email.
  • Classifying support tickets by type and urgency.
  • Extracting data from invoices or PDF forms.
  • Generating product descriptions or follow-up emails.
  • Summarising meetings and pulling out the agreed tasks.
  • Finding information inside internal documentation.

Step 2: measure before touching anything

Without a baseline you will never know whether AI helped. Before the pilot, measure:

  • Weekly hours spent on the process.
  • Volume: how many items get processed.
  • Cost per processed unit.
  • Current human error rate, so you are not comparing AI against imaginary perfection.
  • Current response time to the customer.

Step 3: pick the model for the case, not for the hype

  • General cases (chat, summarising, classification): the small, fast models in each family. Cheap and good enough.
  • Complex reasoning: the large models. More expensive, better quality — use them where the decision matters.
  • Sensitive data with no cloud: self-hosted open-source models.
  • High volume at low cost: optimise the prompt to cut tokens before switching models.

Step 4: RAG before fine-tuning

Most companies do not need fine-tuning. They need RAG: giving the model access to your documents so it answers with your information, not the generic version it learned online.

  1. You gather manuals, procedures and knowledge base.
  2. They are split into chunks and stored in a vector database.
  3. When someone asks, the most relevant chunks are retrieved.
  4. The question plus those chunks go to the model.
  5. The model answers citing your sources.

RAG is cheaper than fine-tuning, updates itself when the documents change, and the answers are verifiable.

Step 5: guardrails from day one

  • Token limits per request to control cost.
  • Rate limits per user to prevent abuse.
  • Content filters: topics the system must not weigh in on.
  • Human escalation when the system is unsure or the customer asks for it.
  • Full logging: every answer must be traceable and auditable.
  • Periodic evaluations: a test set that runs weekly to catch regressions.

Step 6: a real pilot, not a pretty demo

  • It runs in production with real users, not just you testing.
  • It compares the before-and-after metrics you set in step 2.
  • It has a decision date: in X weeks you review and decide to scale, adjust or drop it.

What it really costs to start

Project typeDevelopmentMonthly running cost
Simple pilot (assistant with RAG)2,500 – 8,000 USD100 – 400 USD
Mid pilot (agent that executes actions)6,000 – 18,000 USD200 – 1,000 USD
Production system with several sources15,000 – 60,000 USD500 – 3,000 USD

Running cost scales with volume. In the projects we have delivered, break-even usually lands between week 4 and week 12 when the case is well chosen.

Mistakes that burn budget

1. Starting with the hardest case

People pick «the one that hurts most», which is also the slowest to show results. Start with the easiest one with the highest volume: you gain learning speed and internal credibility.

2. Not defining what «success» means

Without a clear metric, someone will always say it does not work. Set something checkable: «answers 80% of frequent questions correctly» or «extracts data with under 5% error».

3. Buying from the slide deck

AI vendors sell ideal scenarios. Test with your data, your case and your team. If you cannot run a pilot, do not buy it.

4. Adding AI where a good process already exists

If a well-built form solves the problem, do not add AI for fashion. AI is expensive: use it where it competes with human hours.

5. Leaving the team out

If the team feels AI is coming to replace them, the project sabotages itself. Say from the start which work it removes and which it does not.

Cases we see working

  • Professional services: 24/7 booking and FAQs in clinics, law firms and consultancies.
  • E-commerce: generating descriptions and copy for large catalogues.
  • Technical support: automatic ticket classification and first-line answers.
  • Logistics: agents that order routes and estimate times from historical data.
  • Back office: extracting invoice data and reconciling it.

When NOT to start with AI

  • When the process is not standardised: AI cannot stabilise what is undefined.
  • When you have no digital documents for RAG because everything is on paper.
  • When errors carry serious legal consequences and there is no compliance framework.
  • When the volume is so low that maintenance is not worth it.

How we help at Seelight

In AI and automation we audit processes where AI genuinely helps, run a pilot in two to four weeks, integrate it with guardrails and keep evolving it. A 100% remote studio, in Spanish or English.

If you are considering AI but do not know where to start, book half an hour: we identify three concrete processes and tell you honestly whether it is worth it.

Keep reading

Start a project