How we use AI
We build with AI, and we build applications that use AI. That rightly raises questions, especially where your company data is concerned. This page answers them plainly, including the things AI cannot do.
Last updated: 12 August 2026
AI as building partner, not decision maker
AI writes a large part of our code. That is why a working prototype within 48 hours is possible. It is emphatically not why the result is correct: that comes from someone with domain knowledge giving the brief, judging the output and rejecting what does not hold up.
Every release is tested with the people who will actually use it. What fails that test does not ship. No code is delivered that only a language model has seen.
What happens to your data
This is the question that matters, so the answer is explicit:
- Your company data is not used to train AI models. Not by us and not by our suppliers; we work under business terms that exclude training on customer input.
- While building we work with invented test data wherever possible, rather than a copy of your production database.
- If real data is needed to build something, we agree in advance which fields and why, and record it in the data processing agreement.
- Personal data of your employees or customers does not go into a prompt without your knowledge and agreement.
AI features in what we build for you
If your application contains an AI feature, say recognising orders from a PDF or proposing a schedule, a fixed line applies.
- An AI output is a proposal, not a decision. The user sees that it came from AI and accepts or rejects it.
- What the AI proposes is traceable: you can see what it was based on.
- Nothing with a legal effect on a person, such as an assessment or a rejection, is applied automatically.
- You choose which model is used and where it runs, and you are told what that costs per month.
- If it does not work well enough, we switch it off. An AI feature that is often wrong costs more time than it saves.
The EU AI Act
The European AI Act classifies applications by risk. In practice the applications we build fall in the lowest categories: tools that support an employee with administrative work. They make no decisions about people.
If a request of yours would fall into a higher-risk category, think of anything feeding into recruitment, assessment or access to services, we say so up front and discuss what that means in obligations. That is not a reason to avoid it, but it is a reason to set it up differently.
Wherever a user interacts with an AI feature, that is visible. Nobody should have to discover they are talking to a model.
What AI is not good at
Being honest about the limits is cheaper in the long run than enthusiasm. AI is poor at knowing your exceptions, because they are written down nowhere. It is poor at judging when a rule does not apply. And it sounds exactly as convincing when it is right as when it is wrong.
That is precisely why every engagement starts with the process and with conversations with the people who run it, not with the model.