AI that earns its place in a real operation
What does an AI custom solution actually involve?
Finding a repeated operational judgement worth encoding, building that judgement into the system of record, and instrumenting write-back and failure so the team can see when the model drifts. At Entrivis this is engineering on production data and processes we already understand: not a standalone AI product parked next to the ERP.
Most AI demos look fine because they never touch the system that pays people, ships stock, or posts invoices. The work that holds is narrower: assessment scoring, document extraction, practitioner-facing decision support, classification pipelines that write structured fields back into Odoo or the adjacent operational store.
Sometimes the right answer is an LLM. Often it is a rule, a mapping table, and a validation step. We will say so instead of selling the more expensive thing.
Where custom AI usually lands
Document extraction and mapping
Lab PDFs, invoices, forms, and free-text notes turned into fields the ERP already expects, with validation before anything posts.
Structured decision support
Practitioner or operator workflows where the model proposes and a human confirms: never a silent write into a clinical or financial record.
Classification and routing
Tickets, documents, and exceptions sorted into the queues people already own, so volume goes down without inventing a parallel process.
Reporting on trustworthy data
AI reporting only after the underlying masters and processes are stable enough to trust. Useful output requires usable data underneath.
Where we have applied it
VitaOne: Functional Lab Reports, built last
We stabilized a fragile Odoo Enterprise system, migrated it to Community, then built an AI-assisted Functional Lab Report loop: upload, extract and map biomarkers, generate the report practitioners and patients work from. Re-run stays available when the source data changes.
Read the VitaOne case study →Blood-test data mapping
A module that normalises laboratory output into the structures the practitioner workflow consumes. Mapping and validation. The clinical reading stays with the clinician.
The model is the easy part
Calling an API is not the engagement. Turning a lab PDF into a report a practitioner will put in front of a patient is. Units differ by lab, biomarkers arrive incomplete or mislabelled, and a raw extract is not a product. We price the closed loop: write-back, validation, and the human gate, not the demo.
If queues, retries, and escalation are the main need, that work lives under AI workflow automation. If logging, drift, and fallback are the gap, start at AI governance and observability.
How a custom AI build runs
Same engagement models as the rest of our work. We scope the operation, not an “AI package.”
-
01
Use-case discovery
Map the decision: volume, cost of error, who is accountable today. Most candidate use cases die here, correctly.
-
02
Architecture before model choice
What the model may do, what it must never do, where a human sits, and where structured output lands in the system of record.
-
03
Build and write-back
The workflow is built into the operational system. Exceptions route to real people, not a discarded log file.
-
04
Evaluation, then sustained ownership
Test sets and the first weeks after go-live are where trust is earned. Prompts and eval sets hand over to you.
Common questions about AI custom solutions
Do we need to be on Odoo for this?
No. Most of this work arrives through Odoo engagements, and write-back paths are cleanest there, but the same pattern applies when the system of record is elsewhere.
Will you tell us if an LLM is the wrong tool?
Yes. A rule engine with a good exception report solves a surprising share of what gets scoped as AI, at a fraction of the cost and with none of the evaluation burden.
Who owns the prompts and the evaluation sets?
You do. Configuration, prompts, and eval sets live in your repository and are handed over as part of delivery.
How do you handle data leaving our systems?
Model routing, retention, and residency are decided in architecture, not after. Where data cannot leave the environment, we design for that constraint first. Our data and hosting posture is on the Trust page.
What if a previous AI build already failed in production?
Start at Rescue & Stabilization. We audit what is live, what is unwatched, and what to keep before we propose another model.
Start with the decision, not the model
Tell us which judgement your team repeats too many times a day. We will tell you whether it is worth encoding.