AI integration services: add AI to the product you already have

Since 2020 we have been building and developing Enerace.Online, an advisory platform for industrial buyers of energy and gas. In its market analysis, news items are pinned to the price charts and each one gets an AI-generated summary the moment it is added. The feature has been live since 2025, in a product with more than 20 functional areas in one codebase, and it came without rewriting the platform. The stack is Python and Django with a GraphQL API, React with TypeScript, React Native, Celery and AWS.

Centrum Komunikacji runs a Polish Sign Language (PJM) interpreting platform that we build in a government accessibility program (see the case study). We added live speech-to-text for hard-of-hearing and late-deafened users. Automatic speech recognition writes a first draft in real time, a transcription specialist corrects it, and only the corrected text reaches the user, as a chat message. The feature runs in production. Personal data is protected by encrypted fields, the option to delete a user's data and an event log.

On a product platform in the home renovation and interior fittings market, an AI chat and a product-search agent run in a separate AI service.

In Generator ETR for PSONI the phone reads the text from a photo of a letter, on the device itself. PDF documents take a separate path on the server before they reach the model. The reading itself is done by ready-made system libraries, Google ML Kit and Apple Vision. The model connection, the text reading and the readability score are in place; the API for other systems is still being built.

A separate AI service is our default architecture for LLM integration. The application's backend has a service layer that calls it, so we can measure the AI part, change it or switch it off without touching the rest of the product.

On the renovation product platform, a flag at project level (ai_enabled) switches AI on, so the feature can be switched off without changing the rest of the product.

In Generator ETR for PSONI the connection to the model is a setting. An administrator changes the address, key, model name and generation settings such as temperature and max_tokens in the Django Admin panel, and the backend containers keep running. A model change therefore does not need a new release of the application.

Which model sits behind the service is a separate choice. A model provider's API is faster to start. When your data cannot leave your infrastructure, we host the model ourselves; see our page on private LLM deployment. Either way, the AI part stays a separate service.

At PSONI's decision the API for other systems will have four endpoints: logging in with a token, generating an easy-to-read text, listing a user's texts and previewing a historical text, which is kept for 30 days. Access uses an API key from the Django Admin panel, and the endpoints can be switched off later.

To connect AI agents to an existing product, we build an MCP server (Model Context Protocol, a standard that lets AI agents call a product's functions) as a thin layer over its REST API. In our own CMS every MCP tool calls an API endpoint, so validation, permissions and logging stay in the API. Agents and chat assistants have their own page, AI agent development, and the server side is covered in MCP server development.

Where a wrong answer has consequences for users, a person or a test checks the output. At Centrum Komunikacji only the text that a transcription specialist has corrected reaches the user. In Generator ETR a script scores each text with the Gunning Fog index, a readability measure, and a reviewer of easy-to-read texts rates real outputs. Jailbreak tests, which try to make the model break its rules, run on every new model iteration.

AI readiness: what we check before implementation

A free consultation leads to a free discovery workshop, which is our AI readiness assessment. We look at four things.

• The product: what it does today and where an AI feature would sit in it.
• The data: what the model would read, and whether that data may leave your infrastructure.
• The rules: the legal, security and company constraints your product works under.
• The task and the test: what the AI should do, and which test will show that it works.

Sometimes the outcome is advice to skip the language model altogether. You leave the workshop knowing what the AI is meant to do and how its result will be judged.

AI implementation: stages

1. Discovery. A free workshop, run with our own AI toolkit, that fixes the scope and the success test.
2. A separate AI service. We build the AI part as a service your backend calls, so the rest of the product stays untouched.
3. Model choice. A model provider's API or a model we host, depending on where your data may go.
4. Quality checks. The test from discovery runs on the output, and where an error is costly a person reviews it as well.
5. Support. After launch we stay on for support and maintenance, because models, prompts and the data they read keep changing.

The scope of AI work is set in discovery. That scope covers the AI service, the model choice and the checks on its output. Copyright to the code passes to you with each payment, within the scope of use defined in the contract.