Agriculture & Livestock · Étude de cas
Put a small AI on the company's own GPU, and ask scattered production, distribution, and quality data from an internal-network browser
Ce que ça vous donneAsk an sLLM running on the company's own GPU from an internal-network browser: RAG answers the questions that need document evidence, the Data-Agent answers the ones that need figures aggregated, and the data never leaves the internal boundary.
To answer a single question, the staff member spends the whole morning moving from desk to desk. Production records are in this system, distribution history in that one, quality reports in yet another folder. They open three screens, copy numbers across, open a report to check one line, then return to the first screen. It isn't that the data is missing. It's just scattered here and there.
Uploading internal data wholesale to a large AI in an external cloud and asking it questions is not a route they can take. By security policy, production, distribution, quality, and transaction data must not cross the internal boundary. The demand to use AI and the principle that data cannot leave collide head-on.
This agriculture company's data lead faced two questions. Can we get AI's help without sending the data out? Is there a way to confirm, before a full contract, that it's usable in our environment, on our data? This piece is a record of the validation that goes looking for the answers — the proof-of-concept (PoC) process before full-scale adoption.
Data overflows, but the answer is nowhere
Agriculture and livestock is a data-rich industry. The records that pile up every day fall into four broad kinds.
- Production records. How much was produced at which farm
- Distribution history. By what route and how far it was distributed
- Quality reports. What was flagged in quality inspection
- Transaction data. Who was traded with, and on what terms
The problem isn't the volume but the location. These records are split across different systems and documents, and to answer a single question the staff member has to shuttle between those sources and stitch them together by hand.
Half the work is collation, not analysis
Here's the current procedure. A question comes in, and three screens go up. Copy the numbers out of the production records, check the route in the distribution system, open the quality report to find one line. In the staff member's own words, half the work is collation, not analysis. More time goes into gathering the numbers needed for a decision than into making it. Once one answer is produced, the next question starts from scratch again, and as long as the sources are scattered, this toil repeats every time.
It's not that there's a shortage of data. The problem was that answering one question meant shuttling between several systems by hand every time.
And the common method — loading the scattered data onto a large AI in an external cloud — can't even get its first button fastened. Sending internal data outside is itself blocked by security policy. With data that can't be taken out, the scope of AI use narrows; give up on AI, and the toil of collation stays exactly as it was. This either-or was the real reason adoption gave them pause.
And one more thing is layered on top. Even if a method existed, the company wanted to confirm — before a full contract — whether it was actually usable in our environment, on our data. The decision to bring in a new tool had to be made on validated grounds, not on the impression of a single demo.
Don't send the data out — bring the AI beside the data
The idea Consilience proposed is one sentence. Don't send the data out; bring the AI beside the data. Instead of an external cloud, a small language model (sLLM, a smaller-scale LLM) is deployed in the customer's internal GPU environment. The data doesn't leave the internal boundary; the AI comes inside that boundary to do its work.
How the AI gets placed inside the boundary
For on-prem, go through "Enterprise" in the plan picker
In the plan picker under Settings → "Account", Free, Plus, Pro, and Ultra all lead to self-serve checkout. "Enterprise" is the entry for an on-prem or dedicated install, so it leads to a contact link instead of checkout.
Deploy the sLLM in the internal GPU environment
The small language model goes on the customer's internal GPU, not an external cloud. The data doesn't step a single foot beyond the internal boundary; the AI comes inside it.
Index the internal documents in advance
Answering a question that needs document evidence means finding the relevant passages first. With internal documents indexed in advance, an incoming question finds its relevant passages and is answered based on where in the documents it's written that way.
Attach a path to query the internal data
Questions that document search alone can't solve — those that require aggregating figures or querying with conditions applied — are fetched by the Data-Agent querying the internal data directly.
The staff member connects through an internal-network browser
There's no separate installation. They reach a web link through an internal-network browser and pose a question. That's all there is to prepare on the user's side.
Instead of three screens, you ask in one place
"What's the criterion behind this item being flagged in quality inspection?"
→ A question that needs evidence written in documents. It finds the relevant
passages in the pre-indexed internal documents first, and answers on top of
that evidence (RAG, retrieval-augmented generation). Where in the documents
it's written that way comes back with the answer.
"What's the total production that matches these conditions?"
→ Document search alone won't solve it. Questions that require aggregating
figures or querying with conditions applied are fetched by the Data-Agent
querying the internal data directly.
(Both questions)
→ Question and answer are both processed on the internal GPU. The data never
leaves the internal boundary.The answers split two ways because the questions come in two kinds. Questions that need evidence written in documents go to RAG. Internal documents are indexed in advance, and when a question comes in, it finds the relevant passages and answers on top of them. Questions that need to be computed from the data go to the Data-Agent, which queries the internal data directly. The two kinds of answers come back combined.
The collation the staff member used to do by hand, moving from screen to screen, happens right here. Nobody shuttles between sources, and the data stays inside the company.
What changes
| Before | Now |
|---|---|
| Answering one question means three screens up and shuttling between systems and documents by hand | You ask and get an answer in one place: a web link in an internal-network browser |
| Loading internal data onto an external cloud AI is blocked by security policy, so it can't even start | Instead of sending the data out, an sLLM sits on the internal GPU, and the data never leaves the internal boundary |
| A person splits the questions that need document evidence from the ones that need figures aggregated | RAG takes the document evidence, the Data-Agent takes the aggregation, and the two answers come back combined |
| Adoption is judged on the impression of a single demo | The agent's questions and answers are gathered as Q-A pairs and checked, and the check results arrive as a deliverable — grounds from running it on their own data |
To sum up: instead of a person shuttling between scattered sources, you ask in one place through an internal-network browser, and the sLLM on the internal GPU answers while the data stays inside the boundary. Whether to adopt is judged on the check results from running it on their own data.