AI integration
AI inside your software, with checks around it.
Most businesses don't need another chatbot. They need the data out of a PDF, a summary of a long email thread, or a draft reply written from their own records. I build these into the systems you already use, in .NET, and make every result checkable.
What I build
Data from documents
Invoices, orders, claims and forms read into structured fields, checked against your rules and existing records, and passed to your system. Anything uncertain goes to a person.
Summaries and drafts
Long documents, email threads or case histories summarized, and replies or reports drafted from your own data, for a person to review and send.
Assistants in your tools
A question box inside the application your team already uses, answering from your documents and showing where each answer came from.
Sorting and routing
Incoming emails, tickets or documents sorted by type, urgency or customer, so they reach the right person or queue.
AI features in .NET software
Model calls behind a clean .NET service with logging, retries, cost limits and tests, so the feature behaves like the rest of your software.
Checks around every answer
Validation against known data, confidence thresholds and a review step where a mistake would be expensive. AI output is never the last line of defence.
Is AI the right tool for this?
Often it is not. When the input is already structured, a rule or a database query is cheaper and more predictable.
| If the task… | Then usually… |
|---|---|
| Works on structured data with fixed rules | Ordinary code or a database query. No AI needed. |
| Reads free text, scans or documents that vary in layout | AI extraction, with validation and human review for uncertain cases |
| Needs answers from your own documents | An assistant that searches your data and cites its sources |
| Has legal or financial consequences | AI drafts or flags; a person decides |
| Involves personal or confidential data | A provider and setup that meet your data rules, agreed before any data is sent |
If plain code does the job, that's what I'll recommend.
How an AI project usually goes
Real samples
We start with a set of your real documents or requests, so results are measured, not guessed.
A small proof
A working prototype on those samples shows the accuracy and the cost per document before you commit.
Agree the scope
A written proposal: what the feature does, how it is checked, what it costs.
Build it in
The feature goes into your software with validation, logging and a review step where needed.
Measure in use
Accuracy and exceptions are tracked, so you see how it performs on new data.
Questions about this
Where does our data go?
To the model provider we agree on, and only the data a task needs. Which provider, which region and whether your data may be used for training are decided before anything is sent. If the data must not leave your environment, we look at whether a model can run there.
How accurate is it?
It depends on your documents, which is why a project starts with a test on real samples. You see the accuracy and the cases it gets wrong before deciding to go further.
What does it cost to run?
Model usage is paid per request. The prototype shows the cost per document or request, so the running cost is known in advance.
Can you add AI to the software we already have?
Usually, yes. If it's built on .NET, or has an API or a database, the new feature can sit next to it without a rewrite.