Plenty of IT companies now say they “do AI.” It’s harder to verify — because the best proof isn’t a slide deck or a logo of a language model provider, it’s a product the company runs in production itself, on its own risk, for real users.

Two kinds of companies that say they “do AI”

In practice, we see two approaches that look similar from the outside and work completely differently underneath.

The first: a company implements AI only for clients. The project ends with a demo, a pilot, a handover — sometimes a production rollout — but the operational risk (model mistakes, query costs, provider changes, model updates) stays with the client, or disappears along with the team once the project wraps up.

The second: a company builds and runs its own product where AI is part of daily operation — not a presentation stage, but month after month, for users who won’t forgive an outage. That’s what “AI running in production” means in the literal sense: the system works when nobody’s watching, and it has to work correctly every single time.

The difference isn’t cosmetic. A company in the second category knows firsthand where AI gets things wrong, what it actually costs to keep a model running, and which control mechanisms are genuinely necessary — because it built them and is on the hook for them.

What changes when AI has to be maintained, not just deployed

An implementation project ends on handover day. Maintenance starts the day after, and it has no end date.

Running AI in production means facing questions that rarely show up in an implementation proposal: what happens when the model misreads a document? What’s the process when the AI provider ships a new model version? What does a single request actually cost at real volume, not in a ten-example test? Where exactly does the AI’s role end and deterministic logic — the kind that can’t “randomly” make a mistake — begin?

Those are the same questions we cover in our piece on separating what AI does from what code decides — in our systems, AI proposes and classifies, while critical decisions (amounts, taxes, legal matches) are always handled by ordinary, predictable code. That’s not a theoretical distinction from an article. It’s the architecture we had to build, because otherwise our own products wouldn’t hold up.

A team that has never kept AI running in production has no way to earn that knowledge firsthand. It can imagine it. We know it from practice.

There’s also the quiet, ongoing work behind the scenes: monitoring model outputs, flagging edge cases, updating classification rules whenever a new document type or a new market shows up. That work has no end date — users keep bringing new variants of the problem that no pre-launch test ever covered.

Three products, one pattern: how it looks inside WebET

WebET is an IT and AI innovation company: we don’t only implement AI for clients — we build and maintain three products where the Claude language model works in production every single day, and we carry that experience directly into dedicated implementations for other companies.

Qkwit — AI-assisted accounting for sole proprietors. AI reads and classifies accounting documents (extracting data from invoices, receipts, confirmations), while taxes and social security contributions are calculated by a deterministic engine, not the language model. We go deeper into this mechanism in AI accounting for sole proprietors.

Taniej po Lek — a basket-based medication price comparator operating across nine countries. Its AI component is Apteczkomat: recognizing what’s in a shopping basket, a chat feature that helps find substitutes, and stock planning. That’s not a demo — it’s a feature real comparator users rely on.

Brokik — a rental management SaaS platform for landlords and tenants, available across 25 countries. AI there handles adapting rental documents to local law and pricing — areas where a mistake isn’t abstract, it’s immediately visible to a user in a different country, under different rental law.

Three different industries, three different uses of AI, one common thread: Claude in production, not on a slide. We carry those same lessons — where AI gets things wrong, how to monitor answer quality, when to escalate a decision to a person — into dedicated implementations beyond our own products, including work with automotive and financial-sector companies.

What this difference means for a client commissioning an implementation

When a team runs its own AI-based products, that firsthand knowledge translates directly into the quality of a client implementation.

First — realistic pricing. A company that has never paid the bill for model queries at real volume can easily underestimate maintenance costs. We know exactly what it costs, because we pay it ourselves, for three products at once.

Second — architecture that assumes control from day one, not just functionality. The “AI proposes, code decides” split isn’t an add-on requested by a client — it’s our default way of building, because otherwise our own products would fail.

Third — a realistic timeline. We know from our own experience that AI implementation requires a careful process audit before any code gets written — because we go through that stage regularly, across three different products.

Fourth — familiarity with edge cases. Three products across three industries add up to hundreds of unusual documents, phrasings, and situations that had to be handled correctly before any user ever reported them as a problem. That knowledge feeds directly into how we design a client’s control mechanisms — ahead of time, not after the first incident.

For a client choosing an AI implementation partner, that’s a practical tip: it’s worth asking not “do you do AI,” but “what do you run it on yourselves, and how long has it been in production.” The answer says more than any proposal ever could.

FAQ

What’s the difference between “implementing AI for clients” and “building your own AI products”? An implementation ends when the project is handed over. A company’s own AI product is maintained indefinitely — at its own cost and risk, which forces a more mature approach to error handling and cost control.

Can a team without its own AI product still implement AI well for a client? Yes, but it has to earn that knowledge on the client’s project, often through trial and error. A team with its own products already in production brings that knowledge ready-made.

Why is “AI in production” more than a demo or a proof of concept? Because a demo works on selected examples, while production has to work on every case — including the unforeseen ones, for years, at real volume and real cost.

How can you tell if a team actually uses AI rather than just talking about it? Ask directly about a specific, working product — not a list of technologies on a slide. We cover more on choosing a partner in how to choose an AI implementation partner.

Does WebET implement AI in industries other than accounting, rentals, or price comparison? Yes — we also work with companies in the automotive and financial sectors, applying the same pattern: AI reads and proposes, code decides. We carry the experience from maintaining our own products directly into those implementations. More on our AI implementation services page.

Let’s talk about your implementation

If you’re considering an AI implementation and want to talk to a team that runs AI in production itself, every day — get in touch.