AI for businesses and professionals: use cases that hold up and projects to avoid

Language models are powerful tools with a precise profile: they excel at reading, classifying, extracting and rewording text, and they are unreliable when asked to remember facts, do arithmetic or make decisions without context. Projects that work start from this profile. Projects that fail start from the technology and look for a problem to solve.

Use cases that hold up

Assistants grounded in a knowledge base

They answer repetitive questions from customers or colleagues using only verified content: terms, procedures, manuals. They work when the knowledge base is curated and the assistant can say "I don't know". I cover them in AI chatbot for your website and AI assistant for internal documents.

Data extraction from documents

Supplier invoices, orders by email, hand-filled forms, contracts: the model extracts the fields into a structured, constrained format, the system validates them, and a person checks only the doubtful cases. It is often the project with the fastest return.

Triage and priority

Incoming requests classified by type, urgency and recipient, with the key data already extracted. The operator does not read everything: they work from an already sorted queue.

Drafts to review

Replies to frequent requests, product descriptions, meeting summaries, first drafts of documents from structured data. The person remains the author; the model removes the blank page.

Semantic search

Finding documents, cases or products similar in meaning, not just by keyword, in internal archives or the site's catalogue.

Projects to avoid

• Starting from the model: "let's use AI for something" produces prototypes nobody uses.
• Automating decisions without oversight: quotes, refunds, sensitive messages sent without human review.
• Using the model as a database: asking it for prices, deadlines or data it should read from a system.
• General-purpose chatbots on the site, with no knowledge base and no limits.
• Projects without measurement, where success is an impression.

How it is designed

1. One process, one metric: time per case, errors, volume handled.
2. A set of real examples with the correct answer, gathered before writing code.
3. Structured, validated output: the model returns data in a schema, the code checks it before using it.
4. Thresholds and handover to a person when confidence is low.
5. A model sized to the task: often a smaller, faster, cheaper model is enough.
6. Release alongside the existing process, comparing results.

Costs and data

Running cost depends on volume and text length; with short answers, caching and the right model it stays contained, but it must be estimated upfront and monitored. On data: providers whose terms exclude training, minimisation of personal data, limited logs, a GDPR assessment. The EU AI Act adds transparency obligations when a system interacts with people.

The people

Projects that work involve whoever does the job today: they know the exceptions, they know where the model will get things wrong, and they are the ones who will use it. The aim is not to replace them but to take the mechanical part off their plate.

A typical example, start to finish

A practice receives dozens of documents from clients every day (invoices, receipts, forms) and someone transcribes the data into the management system.

1. Baseline: how many documents a day, how long each takes, how many transcription errors.
2. Test set: about a hundred real documents, with the correct data filled in by hand.
3. Extraction: the model returns the fields in a defined schema; the code checks formats, totals and date consistency.
4. Threshold: below a certain confidence level, or if a check fails, the document goes to a review queue with the fields already filled in.
5. Shadow run: for a few weeks the workflow runs alongside the manual work, and results are compared.
6. Release: the person no longer transcribes, they only check the doubtful cases.

The result is measured with the same indicators as the baseline. If it does not improve, the project stops: that is a useful outcome too.

My take

I use AI every day and integrate it into projects, but with a clear idea: it is a component, not the product. The Altura Vela management app has AI features that take repetitive work off whoever organises courses and outings, inside an application with its own data model and checks. In Fix and Sail's Captain, the assistant answers from the manuals of the accessories on that boat. The chat on this site answers only from a knowledge file and refuses the rest.

In all three cases the value is not in the model, which can be swapped, but in what surrounds it: the right data, the limits, the code that checks the answers.

There is another aspect I consider decisive: reversibility. Models improve and change price every few months, and a project built around a single provider's quirks ages quickly. That is why I always separate the application logic from the model: instructions, output schemas, test set and checks live in the project's code, and the model is a replaceable component. When a better-suited model comes out, the test set is re-run and the decision is made on numbers, not promises. It is the same principle I use for every other dependency: few, replaceable, under control.

Why work with me

I have been programming since 1999, delivered more than 300 projects and work as an external developer with about 30 agencies, from Rome and remotely. I integrate language models into websites, management systems and workflows with validated output, measurement and care for data.

If you want to understand where AI could really help your business, get in touch: in a call of about 20 minutes we pick a process and a metric. The service is in AI and automation.