How can an AI assistant be integrated into veterinary software without compromising security?
With Silice, the AI assistant built into VetCoreSolution®, permissions remain enforced by the server and every change requires the user's approval.

Pierre Bony
President, co-founder and CTO
Asking artificial intelligence to summarise a document has become relatively commonplace.
But asking it to retrieve an animal's medical history, analyse a clinic's schedule, prepare an appointment, or follow up on overdue invoices is another matter entirely.
To perform these operations, AI needs access to the software's data, an understanding of how it works, and the ability to interact with its features.
How can we give it these capabilities without compromising the security of the clinic's data? And above all, without granting it more permissions than the user talking to it?
This is one of the questions we had to answer when developing Silice, the AI assistant built into VetCoreSolution®, our veterinary practice management software.
Our approach rests on a simple principle: artificial intelligence must use the same services and follow the same rules as the rest of the software.

An architecture designed to accommodate artificial intelligence
Integrating an AI assistant into business software should not require rebuilding the software.
The key is to design the software from the outset so that its features can communicate with one another and with external tools while respecting the security chain.
From the initial design of VetCoreSolution®, we chose to separate business functionality from the user interface, with APIs allowing the different components to communicate with one another.
Creating an appointment, searching for an animal, viewing an invoice, or retrieving a medical history: these operations rely on business services already present in our software.
The VetCoreSolution® interface uses these services to respond to user actions. Why should an AI assistant take a different route?
This is where MCP (Model Context Protocol) comes in: an open standard that allows AI assistants to interact with applications and their tools.
In VetCoreSolution®, our MCP layer relies directly on existing business services. It exposes the operations available to assistants without having to duplicate the software's logic.
Silice can therefore search for information, query the schedule, consult records, or analyse data using the same mechanisms as the application.
Above all, the business rules and security checks remain those of VetCoreSolution®.
There is no need to bend the software out of shape to integrate AI.
Security: no special privileges for AI
This is probably THE most important point of the entire architecture.
An internal AI added at a later stage may have technical access far beyond that of the user. If this access is poorly controlled, security then depends on the model's ability to follow its instructions.
In other words, it is given the means to access restricted data, then politely asked not to do so.
Anyone who has used AI models will understand why this approach is problematic.
At CoreFactor, we have chosen a much stricter separation.
Silice works with the permissions of the signed-in user. No more.
Let's take a concrete example.
A clinic staff member is not allowed to view the practice's financial information. Yet they ask Silice:
“What is our revenue this month?”
They can try... But Silice itself has no way to access that information.
This is not a prohibition written into its instructions: VetCoreSolution® servers enforce the permissions.
Our architecture goes even further:
- The available tools are filtered according to the user's permissions.
- Every call is checked again by the server, even if the AI attempts to use a tool it should not have access to.
- An external connector's authorisations can further restrict access, never extend it.
- Authentication rules, including two-factor authentication where required, continue to apply.
AI therefore does not choose which permissions it wants to respect.
It can only use the features that the software actually allows it to use.
This is a fundamental difference: our security does not depend on the reliability of an AI model's reasoning.

Silice prepares actions; the user stays in control
Accessing data is one thing. Changing it is another.
An assistant that can consult an animal's record is useful. An assistant that can create or update information directly in the software can be even more useful.
But AI can make mistakes.
It may misinterpret a request, select the wrong appointment, or propose incomplete information. It would be dangerous to assume that all its proposals should automatically become final operations.
That is why we have adopted a cautious approach to how Silice works.
Silice never directly changes the clinic's data.
When a user asks it to create an appointment, update a client record, or prepare a task, the assistant retrieves the necessary information and builds a proposal.
This proposal is then presented in the VetCoreSolution® interface in a form the user can review.
They can approve it, reject it, or correct it.
Only when the user approves does the application actually execute the action, through its usual APIs and with the user's permissions.
The distinction matters: it is not the AI that writes to the database. It is the application, acting on the user's decision.

This principle will also apply to new Silice features, including overdue invoice reminders, planned for the near future.
The assistant will be able to group the relevant invoices and prepare reminder messages by email or SMS. But sending them will remain subject to user approval.
AI proposes. You stay in control.
This is one of the foundations of the relationship of trust we want to build with VetCoreSolution® users.
Silice works within the software, not alongside it
This architecture has another important consequence: Silice is more than an additional chat window.
It can draw on VetCoreSolution® information and features to support users in their daily work.
Silice can also direct users to the records and information it finds directly within the software.
The goal is therefore not to create a chatbot into which clinic data must be copied and pasted to obtain an answer.
The goal is for the assistant to work with the information already present in VetCoreSolution®, within the software that teams use every day.
An open platform: Silice is not your only option
We designed Silice to offer an experience directly integrated into VetCoreSolution®.
But we do not believe that a software vendor should impose a single AI assistant on its users.
This is also one of the benefits of an architecture based on open standards.
The MCP layer used by Silice is also accessible to compatible external assistants. A clinic can therefore connect other tools, including ChatGPT, Claude, or solutions developed by competitors.
This openness obviously does not mean that any assistant can freely access the clinic's data.
External connections rely on authentication and authorisation mechanisms, including OAuth, with explicit consent and controlled permissions.
Each assistant can only access the features made available to it, within the limits of the user's permissions and those defined for its connector.
As with Silice, these checks are performed by VetCoreSolution® servers, not by the AI model.
The choice of assistant must never undermine the software's security rules.
This openness is part of a broader approach that we previously presented in an earlier TechNotes article: building a veterinary platform capable of communicating with other tools, rather than a closed ecosystem.
AI must adapt to the software, not bypass its rules
Artificial intelligence offers considerable opportunities to simplify daily work in veterinary clinics.
But giving it access to business data and features comes with a particular responsibility.
The real challenge is not just choosing a capable model or providing it with a large number of tools. It is building an architecture in which its capabilities remain controlled.
For VetCoreSolution®, we chose to rely on existing services, keep permission checks on the server, require user approval for changes, and allow external assistants to be integrated.
Our goal is not simply to add AI to VetCoreSolution®.
It is to enable artificial intelligence to truly work within the software, alongside veterinary teams, without sacrificing the security of their data or their freedom of choice.


