AIBusiness softwareGDPRMethod
Adding AI features to a business application
7 min read
Adding AI to a business application usually means giving it one precise, checkable job: reading a document to extract fields, transcribing dictated input, or finding an answer in your internal documentation. These features can be built into an existing application in a few weeks, are paid for by usage, and stay safe on one condition: the AI suggests, a person confirms.
This guide covers the use cases that work, what AI costs once it is live, the risks to design for from day one, and a way to start without exposing your data.
Where businesses stand
AI is no longer limited to large corporations, but it is still a minority practice. According to Eurostat, 19.95% of EU enterprises with at least 10 employees used at least one AI technology in 2025, up from 13.48% in 2024. The gap by size is wide: 17% of small enterprises against 55.03% of large ones.
The same survey shows why the others hold back. Among EU enterprises that had considered AI without adopting it, 70.89% cited a lack of relevant expertise, 52.52% a lack of clarity about the legal consequences and 48.83% concerns about data protection and privacy. Those are exactly the three questions a well-scoped project must answer: who builds it, under which rules, and with what data.
Use cases that work
Good AI features share three traits: a repetitive task, an output a user can check quickly, and a mistake that costs little when caught.
| Use case | What the AI does | Human check |
|---|---|---|
| Document reading | Extracts supplier, amounts and dates from an invoice or delivery note | Fields confirmed before saving |
| Voice input | Transcribes a note dictated in the field into the right form | User reviews the record |
| Internal search | Answers a question by quoting your own procedures | Link to the quoted source |
| Summary and triage | Summarises a long file, routes incoming requests | Manual reassignment possible |
| Drafting help | Suggests a first draft of a reply, report or quote | Only the user can send it |
Document reading is often the first win. A team that re-types invoices, delivery notes or certificates every day sees its work shift from typing to checking. The application shows the document next to the suggested fields, and the user corrects what needs correcting.
Voice input serves field teams: an engineer dictates a job report between two visits, and the application transcribes it and fills in the form. The gain comes less from transcription than from putting each piece of information in the right field.
Search across internal documentation handles the repetitive questions ("which procedure applies to this customer?", "what rate for this case?") by quoting the original passage. It requires the application to show only the documents each user is allowed to see, which is an access-control question before it is an AI question.
What AI must not do alone
A language model produces plausible text, not true text. It can invent a reference, misread a figure or answer confidently outside its scope: this is what people call a hallucination. Three rules follow.
- No decision about a person without review. A refusal, a sanction or an individual price must be confirmed by someone. Under Article 22 of the GDPR, people have the right, with some exceptions, not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them. The UK GDPR keeps an equivalent framework, explained in the ICO guidance on AI and data protection.
- Always show the source. An extracted field points to the area of the document; an answer points to the paragraph it quotes. Users check in one click instead of taking the output on trust.
- Keep a manual path. If the AI provider is down, people must still be able to enter data by hand. AI should speed up the work, never become a single point of failure.
Data is the real question
Before choosing a model, work out which data goes where. When personal data is sent to an AI service, that provider usually acts as a processor under Article 28 of the GDPR: you need a data processing agreement, and you should check where the data is hosted and how it is used, in particular whether it can be reused to train models.
The options, from simplest to most controlled:
- An AI service hosted in your region, with a contractual commitment not to reuse your data.
- AI accessed from your own cloud account, so documents, indexes and logs stay in an environment you control.
- An open model on your own servers, so no data leaves at all, at the price of infrastructure to run and sometimes lower answer quality.
In every case, send only what is needed: a document to analyse does not need the full customer record attached. The wider obligations are covered in our GDPR checklist for a business application.
What AI costs once it is live
The budget has two parts.
The build. Adding an AI feature to an application is mostly ordinary software work: the review screen, storing results, permissions, error handling and logging. The call to the model itself is a few lines; everything around it is what makes the feature reliable.
The usage. Model providers bill by volume, based on how much text is sent and generated. Your running cost therefore depends on three choices: the model (a small one is often enough to extract fields), the size of what you send, and the frequency (on demand, or automatically on every document). Before launch, measure the cost on a real sample of your documents and multiply by your volumes. That is the only figure worth trusting.
Then add monitoring (correction rate, response time, spend) and the work of adjusting instructions when your documents change. That belongs in the application's maintenance budget, like everything else.
The regulatory frame, briefly
The EU AI Act sorts AI systems by level of risk, and it applies to companies outside the EU too when their systems are used in the EU. Most of the uses described here (extraction, transcription, document search) are not high risk, but some transparency duties apply, such as telling people when they are interacting with an AI system. Uses that touch hiring, employee evaluation or access to credit fall under a much stricter regime. The timeline and the roles are explained in our guide to the EU AI Act for companies building software.
A way to start
- Pick one task, frequent and checkable, and measure how long it takes today.
- Test on your real documents. Fifty examples are often enough to know the error rate before promising anything.
- Design the review screen before the automation: that screen is what makes AI safe to use.
- Release to a pilot group, track the corrections, then widen.
It is the MVP approach applied to AI: one useful, measured feature before adding more, as described in our guide to what to build first in an MVP. We also use AI ourselves to write code, always with human review at every step, which is part of how we work.
Where to start
Write down the task you would like to hand to AI, with one real example of a document or an entry. At LPR Studio, the visual prototype is free and presented in a video call within 5 working days, wherever you are: it shows the screen where the AI suggests and your team confirms, before you commit to anything. Our three ways to fund the build are on our offers page.